Fun with NULL pointers, part 1 [LWN.net]

Fun with NULL pointers, part 1

Posted Jul 20, 2009 21:39 UTC (Mon) by proski (subscriber, #104) [Link] (18 responses)

We should ensure that setuid programs exit immediately if they are using non-default personalities.

Fun with NULL pointers, part 1

Posted Jul 20, 2009 21:53 UTC (Mon) by drag (guest, #31333) [Link] (17 responses)

It would be a lot better just to do away with setuid binaries altogether.

That's what things like policykit and dbus are for...

Fun with NULL pointers, part 1

Posted Jul 20, 2009 23:33 UTC (Mon) by nix (subscriber, #2304) [Link] (15 responses)

Oh yeah great. So instead of locating setuid binaries and knowing that
*that* is my vulnerability surface, I have to parse a huge pile of XML and
hope that there are no bugs in policykit and dbus that might cause
unintended things to be run (and we know there have been *none* like that
before). The setuid implementation in the kernel is tiny and trivially
auditable by comparison, sharing virtually all its code with the
tested-to-death-and-hopefully-audited ELF execve() implementation.

PolicyKit has been done right once before. It was called 'userv'.
PolicyKit itself is a huge step backwards if you actually want security.

Fun with NULL pointers, part 1

Posted Jul 21, 2009 7:21 UTC (Tue) by gmaxwell (guest, #30048) [Link] (7 responses)

Yea policy kit. Great stuff.

By default fedora allows the desktop users to change the system time. All they must do is ender the *user's* password (not root!) and even that they only have to do it once.

Great stuff great stuff.

Although many people have pointed out the terrible security implications nothing has been done. Sometimes it really does take some high profile compromises to get things fixed.

Fun with NULL pointers, part 1

Posted Jul 21, 2009 9:45 UTC (Tue) by cortana (subscriber, #24596) [Link] (6 responses)

But that's not the fault of PolicyKit itself. Rather it's the fault of the distributor who shipped it with a policy that a) allows an unprivileged user to change the system time and b) does not force them to re-authenticate whenever they wish to do so.

Concerns about the increased vulnerability surface caused by the complexity of PolicyKit are still justified, but Fedora's default policy being stupid is not relevant to that discussion. If we wanted to blame the system for allowing the user to do stupid things then we may as well all give up and move back to Windows. :)

Fun with NULL pointers, part 1

Posted Jul 21, 2009 9:56 UTC (Tue) by nix (subscriber, #2304) [Link] (5 responses)

The concern isn't just that the vulnerability surface has increased: it's that we can't even easily tell what it is anymore.

Determining the set of privileged code that could carry out operations on behalf of unprivileged users was fairly simple in the days before PolicyKit: find setuid/setgid binaries, chase their shared library dependencies and (if you're paranoid) see what they can dlopen(). Just a grep away, in any case.

Now, we have to analyze the dbus and PolicyKit policies as well, and XML is... not terribly amenable to analysis with Unix-style shell tools. (Some Perl packages come with XML-style XPath-based grep tools, but they are a) rarely installed and b) seriously cumbersome. We really need an awk for XML.)

Fun with NULL pointers, part 1

Posted Jul 21, 2009 12:52 UTC (Tue) by nim-nim (subscriber, #34454) [Link] (1 responses)

> We really need an awk for XML.

Just use xsltproc directly (though not having to use a detached xslt file would be nice)

Fun with NULL pointers, part 1

Posted Jul 22, 2009 22:00 UTC (Wed) by nix (subscriber, #2304) [Link]

Ew, no. Utterly un-awklike and doing awk-like transformations with XSLT is
really quite painful. (And yes, you can do awklike languages for things
other than text streams: see gvpr(1) for example.)

(One of many problems is XSLT's heavy use of <>, which makes it very
annoying to use from the shell prompt. Another is its astonishing
verbosity. Another is its total lack of good taste in design... also the
functional nature of it, while one of its nicer aspects, fits very badly
with the shell in my experience.)

Fun with NULL pointers, part 1

Posted Jul 21, 2009 14:01 UTC (Tue) by gmaxwell (guest, #30048) [Link]

Poliykit plays a role: If you go look at the discussions on the fedora list you'll see that there was some degree of argument what the actual behaviour was Was it asking for a password at all (some people thought it wasn't because it only did so once) and was it asking for the root password? A lot of people had used and never realized that it was asking for their user password rather than root.

SUID is more unambiguous.

xml awk

Posted Jul 22, 2009 7:08 UTC (Wed) by Frej (guest, #4165) [Link] (1 responses)

xml cli tool
http://xmlstar.sourceforge.net/

xml awk

Posted Jul 22, 2009 11:18 UTC (Wed) by nix (subscriber, #2304) [Link]

That looks nice. Not very awkish though...

Fun with NULL pointers, part 1

Posted Jul 21, 2009 10:18 UTC (Tue) by cortana (subscriber, #24596) [Link] (4 responses)

You don't have to start at the XML. You can ask the PolicyKit daemon itself what you are currently allowed to do by running polkit-auth; you can get a list of everything you could possibly do with additional authentication by running polkit-auth --show-obtainable; and you can see all the actions that it is possible to perform on a system, and find out which users may perform that action, by running polkit-gnome-authorization. Of course, this requires you to trust that the PolicyKit daemon has not already been compromised. ;)

I also think the docs for PolicyKit are pretty good; the library reference manual contains a Design Overview at <http://hal.freedesktop.org/docs/PolicyKit/ref-design.html> that explains how all the parts of the system fit together.

Of course the system is much more complex than the setuid mechanism in the kernel, but--assuming it is audited well--it has the potential to increase system security a lot, because it would allow you to eliminate other setuid programs on the system.

There is certainly no shortage of badly written programs that are installed setuid, but fail to give away all additional privileges but the exact ones it wishes to keep and deal with any of the infinite combinations of things an attacker may do to them before exec is called, such as messing around with the PATH or another similarly dangerous environment variable; creating symlinks that will cause a badly written 'create temporary file' routine to overwrite vital system files; mapping memory to address 0 to bypass security checks in the kernel (http://lwn.net/Articles/342330/ anyone?) :)

And of course, setuid does not only consist of one system call, but several (setuid, seteuid, setreuid and setresuid), all with subtly different semantics--sometimes modifying the saved user id, sometimes the real user id, yet others the effective uid... oh, and don't forget setfsuid and the capability mechanism. And the fact that different versions of different operating systems all implement subtly different semantics for these system calls... check out Setuid Demystified <http://www.eecs.berkeley.edu/~daw/papers/setuid-usenix02.pdf> and the Secure Programming for Linux and Unix HOWTO <http://www.dwheeler.com/secure-programs/Secure-Programs-H...> for more details and other attack mechanisms.

So yeah, PolicyKit is complicated--but is it more complicated than the intersection of the setuid mechanism and all the other stuff an attacker can do to a setuid process before it is executed? :)

Fun with NULL pointers, part 1

Posted Jul 22, 2009 11:19 UTC (Wed) by nix (subscriber, #2304) [Link] (2 responses)

So the only way you can see what actions can be run on a system with privilege is... to run a GNOME-specific GUI application?

*sigh*

Fun with NULL pointers, part 1

Posted Jul 22, 2009 12:49 UTC (Wed) by cortana (subscriber, #24596) [Link] (1 responses)

It's not GNOME-specific. It just uses GTK+. Yes, it's unfortunate that there is no command-line equivalent, but it shouldn't be too difficult for one to be written--you are just querying the PolicyKit object after all.

Fun with NULL pointers, part 1

Posted Jul 22, 2009 21:59 UTC (Wed) by nix (subscriber, #2304) [Link]

I think one is essential if PolicyKit can be considered safe to use: we
have to be able to do automated audits and yell at unexpected quiet
changes, lest we miss attacks or accidental fumbles opening up holes.

You're quite right on the fugliness of the UID-setting syscalls in Unix,
but this is not helped by introducing *more* :/ again, userv did all this
better (IMNSHO) many years ago. Why more people don't use it I have no
idea.

Fun with NULL pointers, part 1

Posted Aug 7, 2009 12:21 UTC (Fri) by jschrod (subscriber, #1646) [Link]

I'll have to say that I don't find PolicyKit's documentation very good. I don't know how it is for a developer, but for me as a long-time Unix admin it was frustrating when I had to delve into it a few weeks ago for the first time.

The document linked by you was one of the 1st that I read, btw. It's not that I didn't understand what PolicyKit was supposed to be doing, that was quite clear from the start. And not even that I couldn't read the config files -- while being rather chatty, they were understandable.

Where I didn't succeed, is finding concise information about the overall architecture: how PolicyKit / ConsoleKit / HAL / D-Bus / pam / login processes, both X and console, are *supposed* to work together. That would have delivered pointers to information sources that could have answered questions like Where are the names in the PolicyKit XML files from? Which possible names exist on a given system? Which daemons are started and by whom? What are common PolicyKit authorizations, since it is all about policy and nothing about content? The output of polkit-auth --show-obtainable is not sufficient, IMHO. E.g., I'd need to know what org.freedesktop.hal.lock is, and googling it on site:freedesktop.org does _not_ provide an adequate answer, at least not for me. (And yes, I've read http://people.freedesktop.org/~david/hal-spec/hal-spec.html.)

It was not easy to find the answers to such questions in reasonable time frames because the overall structure had to be laborously reverse engineered by yours humbly. Well, maybe my Google foo may simply be not good enough.

Just my 0.02 EUR. :-)

Joachim

Fun with NULL pointers, part 1

Posted Jul 22, 2009 2:14 UTC (Wed) by Baylink (guest, #755) [Link]

"vulnerability surface".

Wow. That's an altogether neat concept. Thanks.

Fun with NULL pointers, part 1

Posted Jul 25, 2009 2:13 UTC (Sat) by mikov (guest, #33179) [Link]

I am with you.
In my mind the key to reasonable security is simplicity. SUID is extremely simple. Compare changing a user's password using passwd to what has to happen in Windows.

Fun with NULL pointers, part 1

Posted Jul 21, 2009 8:37 UTC (Tue) by mmahut (guest, #45550) [Link]

It will eventually go away if we start using file system compatibilities. As far as I know, they've been already implemented in Fedora 10, but RPM will support it just from Fedora 12.

http://udrepper.livejournal.com/20709.html

Fun with NULL pointers, part 1

Posted Jul 21, 2009 0:26 UTC (Tue) by kpfleming (subscriber, #23250) [Link] (1 responses)

What? pulseaudio is setuid-root *and* allows non-privileged users to load modules into its process space? What kind of insanity is that?

Fun with NULL pointers, part 1

Posted Jul 21, 2009 2:13 UTC (Tue) by smurf (subscriber, #17840) [Link]

A setuid program loading unprivileged modules usually isn't a problem if that program drops its privs before doing so.

Usually.

This whole mess goes to show that security is a hard-to-solve problem.

Taking privs off pulseaudio (Linux has been capable of doing better than all-out-setuid for _how_ long, exactly ?!?) may or may not be the solution in this case, I haven't checked.

Fun with NULL pointers, part 1

Posted Jul 22, 2009 14:24 UTC (Wed) by mezcalero (subscriber, #45103) [Link] (1 responses)

pa 0.9.16 is not setuid anymore, because the introduction of rtkit makes that unnecessary.

Fun with NULL pointers, part 1

Posted Aug 15, 2009 9:01 UTC (Sat) by gvy (guest, #11981) [Link]

Yeah, previously one had to introduce a rootkit. Now it's half-done by prominent distributors. :(