Posted Oct 13, 2009 8:25 UTC (Tue) by michaeljt
In reply to: SELinux
Parent article: LPC: Three sessions from the security track
The basic idea of UNIX permissions is simple, but gets hairy once you start including setid bits, setgid on directories and the sticky bit. It's used for everything from protecting home directories to providing controlled priveledge escalation to stopping people from deleting other people's temp files and ensuring new files are readable by certain groups. However, it does have the advantage that most people understand it, which is not true for SELinux.
I have to agree with you there (on both points). Apart from basic usage of setuid I have similar feelings about those "extra bits" to SELinux :)
What makes it mandatory access control is that the owner of the object doesn't get to say what happens, the policy is decided elsewhere.
As far as I can see though, in practice it is normally used for restricting things done by the superuser account, which PolicyKit does using "standard" Unix mechanisms - I could imagine a variant on PolicyKit which used a setuid helper instead of a daemon waiting over DBus (not criticising DBus, but it is aimed at doing things from a running desktop, and not at a deeper level in the system, like e.g. (re-)starting DBus itself!), and which starts helper applications as other users than root where appropriate (classical example, passwd: make it owned by user passwd, and have a tool with user permissions get the new password and call a PolicyKit-style helper running as user passwd to actually set it. And there you have your configurable policy (PolicyKit's policy), your roles (the user passwd) and your restrictions (only do what user passwd is allowed to do, namely, change the password file).).
Of course, SELinux does do many other things, like competing with PaX by preventing applications from changing their code while running. See my point above :)
to post comments)