[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 18 Apr 2021 13:25:47 +0100
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
Cc: security@...ian.org
Subject: Re: xscreensaver package caps gets raw socket
On Sat, 17 Apr 2021 at 07:31:05 -0700, Tavis Ormandy wrote:
> Hello, I noticed that at least debian (maybe others) ship xscreensaver
> hack with cap_net_raw enabled:
>
> $ getcap /usr/libexec/xscreensaver/sonar
> /usr/libexec/xscreensaver/sonar cap_net_raw=p
...
> - In theory, mesa support running in a privileged context, their
> documentation says they disable dangerous features in setuid/setgid
> binaries:
>
> https://mesa-docs.readthedocs.io/en/latest/egl.html
I don't think it's actually very realistic to expect something the size of
Mesa to be safe to use in a process that elevates its capabilities above
those of its caller, because to achieve that, it would have to distrust
the entire execution environment (environment variables, inherited file
descriptors, rlimits...), and this level of distrust would have to be
maintained across all of Mesa, including all its drivers, plugins and
dependencies.
I've seen this before in multiple implementations of D-Bus (at least
dbus and GLib), where reading environment variables is part of the "API"
and so cannot be stopped without consequences. We tried to harden the
libraries by distrusting the environment when AT_SECURE, but had to revert
the hardening because it caused otherwise-working programs to regress as
a result of refusing to read environment variables. A frequent example
was gnome-keyring, which historically had CAP_SYS_RESOURCE, to be able
to mlock more memory when ordinary user processes couldn't.
In both dbus and GLib, maintainers took the position that distrusting
environment variables while AT_SECURE is hardening against insufficiently
careful callers, rather than a security guarantee. If a program is
setuid, setgid, setcap, or has a privilege-escalating AppArmor or SELinux
transition, then it's the maintainer/packager of that program that has
chosen to put the program in the position of being a security boundary,
so it seems reasonable to expect the program to take responsibility for
enforcing the security boundary by cleaning up its attacker-supplied
execution environment before calling into arbitrary libraries.
> The problem is that even if we make cleaning up the environment work,
> you're always going to need $DISPLAY, and any code exec bug connecting
> to a malicious X server will be a security bug.... and that sounds super
> hard to get right?
See also e.g. <https://www.gtk.org/setuid.html> for the logical conclusion
of this line of thought. I think that's a lot more realistic than
expecting large libraries to maintain a sufficient level of paranoia
throughout their codebase.
On Sat, 17 Apr 2021 at 07:41:15 -0700, Tavis Ormandy wrote:
> Oh, I also pitched using popen("/bin/ping" ..), but I think nobody is
> really convinced that will work, but I kinda like it :)
That's consistent with the principle of least-privilege, and the widely
cited Unix philosophy of having programs that do one thing well.
If you need to gain privileges, then I think that's a much, much better
approach - ideally a new ping-like program that prints a machine-readable
syntax rather than having to screen-scrape human-readable output, but
if that's not available then ping itself is the next best thing.
IPC to a more-privileged service would be safer still, because
setuid/setgid/setcap has a default-allow-like behaviour (everything
that is not explicitly special-cased is inherited), whereas IPC can be
seen as default-deny (everything that is not explicitly sent/received
is not shared).
smcv
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
