Fun with NULL pointers, part 1

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? :)