Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
GNU virtual private Ethernet
Device trees II: The harder parts
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)
PolicyKit has been done right once before. It was called 'userv'.
PolicyKit itself is a huge step backwards if you actually want security.
Posted Jul 21, 2009 7:21 UTC (Tue) by gmaxwell (subscriber, #30048)
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.
Posted Jul 21, 2009 9:45 UTC (Tue) by cortana (subscriber, #24596)
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. :)
Posted Jul 21, 2009 9:56 UTC (Tue) by nix (subscriber, #2304)
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.)
Posted Jul 21, 2009 12:52 UTC (Tue) by nim-nim (subscriber, #34454)
Just use xsltproc directly (though not having to use a detached xslt file would be nice)
Posted Jul 22, 2009 22:00 UTC (Wed) by nix (subscriber, #2304)
(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.)
Posted Jul 21, 2009 14:01 UTC (Tue) by gmaxwell (subscriber, #30048)
SUID is more unambiguous.
Posted Jul 22, 2009 7:08 UTC (Wed) by Frej (subscriber, #4165)
Posted Jul 22, 2009 11:18 UTC (Wed) by nix (subscriber, #2304)
Posted Jul 21, 2009 10:18 UTC (Tue) by cortana (subscriber, #24596)
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? :)
Posted Jul 22, 2009 11:19 UTC (Wed) by nix (subscriber, #2304)
Posted Jul 22, 2009 12:49 UTC (Wed) by cortana (subscriber, #24596)
Posted Jul 22, 2009 21:59 UTC (Wed) by nix (subscriber, #2304)
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
Posted Aug 7, 2009 12:21 UTC (Fri) by jschrod (subscriber, #1646)
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. :-)
Posted Jul 22, 2009 2:14 UTC (Wed) by Baylink (subscriber, #755)
Wow. That's an altogether neat concept. Thanks.
Posted Jul 25, 2009 2:13 UTC (Sat) by mikov (subscriber, #33179)
Posted Jul 21, 2009 8:37 UTC (Tue) by mmahut (guest, #45550)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds