| |||||||||||||
CAP_SYS_ADMIN: the new rootCAP_SYS_ADMIN: the new rootPosted Mar 15, 2012 15:35 UTC (Thu) by michaeljt (subscriber, #39183)In reply to: CAP_SYS_ADMIN: the new root by michaeljt Parent article: CAP_SYS_ADMIN: the new root
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...
(Log in to post comments)
CAP_SYS_ADMIN: the new root Posted Mar 15, 2012 16:00 UTC (Thu) by dpquigl (subscriber, #52852) [Link]
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 michaeljt (subscriber, #39183) [Link]
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 (subscriber, #52852) [Link]
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 (subscriber, #52852) [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.
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 michaeljt (subscriber, #39183) [Link]
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.)
CAP_SYS_ADMIN: the new root Posted Mar 16, 2012 9:11 UTC (Fri) by michaeljt (subscriber, #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.
|
|||||||||||||