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.)
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.