CAP_SYS_ADMIN: the new root

Posted Mar 15, 2012 17:19 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

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.