CAP_SYS_ADMIN: the new root

Posted Mar 15, 2012 14:25 UTC (Thu) by dpquigl (guest, #52852)
In reply to: CAP_SYS_ADMIN: the new root by mjthayer
Parent article: CAP_SYS_ADMIN: the new root

I didn't misunderstand you but you don't seem to understand the size of the TCB on a modern Linux system. Its massive and relying on proper auditing of the code is unreasonable. Some even argue that the kernel itself shouldn't be contained in the TCB.

If a malicious userspace binary can expoit a kernel vulnerability it doesn't matter what you do because its game over. You still seem to be missing the idea that protections at a given level can't protect that level reliably. SELinux doesn't claim to protect against kernel vulnerabilities. It claims to contain the accesses made by userspace programs and at best mitigates damage caused by an exploited application by confining the actions the application may take to only what it requires to run (assuming your policy is configured correctly). I'm talking about an exploit in a userspace framework allowing for attacks on other userspace applications. This is entirely reasonable considering its how attacks work today on systems that use simple DAC protections. Own a process running as root and do whatever you want including poke into the address space of other processes. You're trying to argue here that DAC protections are sufficient. This has been shown time and time again to be false. You might want to read up on the MAC vs DAC discussion to see exactly why they are insufficient. POSIX does not provide sufficient access control protections for any modern system.

Also with the exception of the mmap_minaddr bug which Brad found (and was subsequently fixed) SELinux does not grant permissions over your existing permissions. The LSM framework is designed to provide further restrictions not to act as a priviledge granting mechanism. So unless you've found an exploit in SELinux code which allows for arbitrary code execution or memory manipulation in the kernel I'm not sure what kind of buggy SELinux code you'd be referring to.

With respect to trusted path again there is currently no way to do this and relying on userspace to provide a mechanism for trusted path won't work. The fact that any number of components can be overwritten to trick you into typing a password in for an action that isn't the one you think you're authorizing makes that not possible today.

CAP_SYS_ADMIN: the new root

Posted Mar 15, 2012 14:54 UTC (Thu) by mjthayer (guest, #39183) [Link] (8 responses)

Replying to dpquigl:

Just to start with, thanks for your patience here, given that I am no security expert. I won't be offended when you decide to give up, but I am sure that I will learn something in-between. That said...!

> You still seem to be missing the idea that protections at a given level can't protect that level reliably.

I am probably misunderstanding you here somewhere, but I get the feeling that you lump all of user space as one "level". Surely the whole point here is that we have (at least) two levels, a small privileged subset of user space binaries which is the set of policy modules which DBus is configured to start and the set of binaries which a given user is allowed to execute, with DBus and PolicyKit the bridge and the communication mechanism between the two. I suppose I am slightly tainted here by experience of QNX where a lot of what is done in the kernel in e.g. Linux takes place in user space. (And of virtualisation development for that matter.)

> You might want to read up on the MAC vs DAC discussion to see exactly why they are insufficient.

I must admit that my grasp of MAC and DAC is very limited. As far as I can see, DAC is roughly allocating permission to access resources on a per-user basis, whereas MAC is more fine-grained permission to carry out particular actions. But that is also exactly what PolicyKit manages.

> With respect to trusted path again there is currently no way to do this and relying on userspace to provide a mechanism for trusted path won't work. The fact that any number of components can be overwritten to trick you into typing a password in for an action that isn't the one you think you're authorizing makes that not possible today.

The last I heard, the idea for doing that based on today's Linux/X11 systems was to have a second X server which only PolicyKit (that is, the policy modules) has access to and putting up the password prompt along with the clear message about what action was about to be taken there. I'm not sure what the plan was for proving to the user that this was indeed the "privileged" X server (Ctrl-Alt-Fx could verify that, but of course no one will do that every time).

CAP_SYS_ADMIN: the new root

Posted Mar 15, 2012 15:35 UTC (Thu) by mjthayer (guest, #39183) [Link] (7 responses)

Replying to myself:
> I must admit that my grasp of MAC and DAC is very limited. As far as I can see, DAC is roughly allocating permission to access resources on a per-user basis, whereas MAC is more fine-grained permission to carry out particular actions. But that is also exactly what PolicyKit manages.

Taking a look at the CentOS documentation[1] to get an idea of what can be done with SELinux which can't be easily done in other ways, I see examples of things like forbidding a user from making their .ssh keys world-readable. I presume that in practice one would also restrict the set of applications able to read them even as that user. To achieve the same using PolicyKit one would have to have the keys stored in a file to which the user has no access at all and provide a policy module to access the keys. Clearly the SELinux approach has the advantage of being easier to retro-fit. On the other SELinux has something of the feel of a retro-fitted solution.

Basically though if I get it right MAC vs DAC means separating rights to access a file from rights to control its access rights.

[1] http://wiki.centos.org/HowTos/SELinux#head-01f53a6fa1f203...

CAP_SYS_ADMIN: the new root

Posted Mar 15, 2012 16:00 UTC (Thu) by dpquigl (guest, #52852) [Link] (6 responses)

Central administration of security policy is just one property of MAC. The other more important one in SELinux is binding permissions to code and not user identity.

CAP_SYS_ADMIN: the new root

Posted Mar 15, 2012 16:12 UTC (Thu) by mjthayer (guest, #39183) [Link] (5 responses)

dpquigl wrote:
> Central administration of security policy is just one property of MAC. The other more important one in SELinux is binding permissions to code and not user identity.

So you are saying that the key feature of MAC in SELinux which PolicyKit is lacking is that it allows you to say "this action can only be performed by this user or set of users in combination with this binary or set of binaries", rather than just the first part of that? I realise of course that you will wince at the way I formulated that.

CAP_SYS_ADMIN: the new root

Posted Mar 15, 2012 17:19 UTC (Thu) by dpquigl (guest, #52852) [Link] (4 responses)

Its a different level of abstraction. Policy kit makes high level abstractions of what a program does. Like do this privileged operation. SELinux and MAC policies say this program performs these actions on these specific object in the system. These objects can be files or sockets or whatever you like. Its different concept because Policykit really doesn't map policy to system objects. It just maps it to high level concepts exposed by the mechanism. A policykit rule could be that to read my addressbook provided by some other dbus service I need to authenticate myself again. This has nothing to do with how the address book is stored on disk or any of the other resources the address book service needs to function. They are disjoint sets of permissions. Now DBUS has SELinux extensions in it. Where you can say that a process running with a certain SELinux label can contact a "mechanism" aka another service running with a different SELinux label. That's baked into DBUS however no one uses it(To the best of my knowledge). It would strengthen the use of policykit because you couldn't have arbitrary applications contact arbitrary mechanisms and requesting authorization. I guess the point that I haven't made very well in all of this is policykit isn't an access control mechanism. It more resembles an authentication mechanism and access control is still left to the underlying security mechanisms which protect the individual policykit "mechanisms". I really don't like that policy kit called their service providers mechanisms it makes the terminology confusing. Client, service provider, authentication agent make much more sense.

CAP_SYS_ADMIN: the new root

Posted Mar 15, 2012 17:25 UTC (Thu) by dpquigl (guest, #52852) [Link] (1 responses)

It would be nice if LWN had an edit button that tracked the edit history of the comment. That way you can fix stupid grammatical mistakes and because you kept the history you can make sure people don't white wash their comments.

CAP_SYS_ADMIN: the new root

Posted Mar 16, 2012 0:17 UTC (Fri) by filteredperception (guest, #5692) [Link]

"It would be nice if LWN had an edit button that tracked the edit history of the comment. That way you can fix stupid grammatical mistakes and because you kept the history you can make sure people don't white wash their comments."

+1. Yeah yeah yeah I should proofread more before hitting submit, but still... (Not saying that on a tight budget that LWN probably has they should dedicated a lot of resources. Just saying, if somebody has that itch, +1 more person would be gratified)

CAP_SYS_ADMIN: the new root

Posted Mar 16, 2012 5:18 UTC (Fri) by mjthayer (guest, #39183) [Link] (1 responses)

This has strayed pretty far from the original question of what practical things one can accomplish with *capabilities* that PolicyKit can't do, but since we are here... I found the first example (the sshd one) in this posting[1] interesting and educational as to what SELinux MAC is useful for. Obviously one couldn't use PolicyKit to accomplish anything like this, as it is more for controlling privilege escalation than preventing it. And unlike the other person in the discussion, I don't think that privsep is the answer here, as that won't prevent the unprivileged person logged in through ssh from escalating their privileges afterwards through some buggy setuid binary. (Note that SELinux would not protect from a buggy PolicyKit module in the example either, as that would potentially allow the ssh user to trigger an escalation in a different process, though it would be harder to exploit than if it were in the same one.)

[1] http://lwn.net/Articles/103705/

CAP_SYS_ADMIN: the new root

Posted Mar 16, 2012 9:11 UTC (Fri) by mjthayer (guest, #39183) [Link]

To continue off-track and start on the old song - I think that one of the things that irks me most about SELinux is that I have so much trouble nailing down what it is and does, which I think is down to the fact that it doesn't try to solve a precise problem but more to be a general solution to all security issues. As an example, it covers both forbidding people to change the permissions on sensitive files they own, but also forbids binaries from modifying their own executable code without express permission (actually, to add to the confusion, I think there is an official workaround for that involving having two mappings for the memory, one writeable and one executable). Both laudable goals, but perhaps they should be a bit more clearly separated.

DAC vs MAC, and Posix Capabilities

Posted Mar 24, 2012 5:32 UTC (Sat) by gmatht (subscriber, #58961) [Link]

The fundamental difference between MAC and DAC that in MAC the administrator/system decides whether a right is shared while in DAC each object that holds a right makes the choice as to whether to delegate it. Traditional capability operating system such as GNOSIS [1] from 1979 are all about being able to delegate only the rights you want to a particular applications, and those applications in turn being able to delegate rights to modules. But they aren't MAC as such, though you could implement MAC on top of them.

The broad concensus at cap-talk is that MAC is usually a liability, as what you really need is finely divisible rights and the overhead of having to change a central security policy means that MAC systems rarely have finely divisible rights (they also agree that POSIX "capabilities" give true capability systems a bad name). Compare the "capabilities" in POSIX to a traditional DAC Capability system such as GNOSIS/KeyKOS. Most capabilities in KeyKOS aren't equivalent to root, or even the user "nobody". Indeed in KeyKOS a process running with the rights of "nobody" would be considered highly privileged, as it has a huge number of rights. For example, it has direct access to the filesystem which is a highly complex, sensitive and hence exploitable piece of code.

The real argument for MAC is that it stops users delegating rights, the first example given was stopping users sharing their maildir. In general malicious users and objects can bypass this by proxying the right, over a side channel if need be. In practice, the benfit of MAC is stopping users from accidentally doing something stupid. But in MAC there is always a trade off between functionality and security. Maybe the user is going away and wants to allow their friend to access their mail to deal with any important issues that crop up. Pathologically, this may encourage the user to give their friend their password, resulting in even worse security.

In true capability systems, objects can delegate precisely those rights required. So, if an object calls "compress(a,b)" compress gets the right to a and b, but does not even know whether a "c" exists. This doesn't come at the cost of functionality as a well written program should never access variables that are out-of-scope, indeed such a program shouldn't even compile. This makes security an "Inexpensive lunch" [2] because you get it for free with a well decomposed object oriented design. Likewise the progam "gedit" would get the right to modify ~/.bashrc if and only if the user selected .bashrc in the file open dialog box; this can be retrofitted to existing POSIX applications, often without even a recompile [3]. In a traditional MAC system the admin would have to decide which rights gedit should have, and would probably just decide to give it rights to the whole home directory.

[1] http://www.cis.upenn.edu/~KeyKOS/Gnosis/Gnosis.html
[2] http://wiki.erights.org/wiki/Walnut/Secure_Distributed_Co...
[3] http://plash.beasts.org/powerbox.html