←back to thread

Linux Capabilities Revisited

(dfir.ch)
190 points Harvesterify | 1 comments | 22 Oct 25 13:50 UTC | HN request time: 0.199s | source
Show context
surajrmal ◴[22 Oct 25 14:42 UTC] No.45669852[source]▶
A shared global namespace ultimately makes it very difficult to have a decent capability based security system. Namespaces limited to the set of actions you have and a hierarchy of capabilities whereby children can only be given access to capabilities their parents have is required for a sane view of how things work. Much like encapsulation makes it easier to reason about abstractions in a program, this nested hierarchy of capabilities makes it easier to reason about the privilege of various parts of the system. Instead we have soup where no one can quite reason about what has access to what.
replies(6): >>45670120 #>>45670198 #>>45670857 #>>45671117 #>>45671465 #>>45674367 #
PaulHoule ◴[22 Oct 25 15:01 UTC] No.45670198[source]▶
Note it is just a set of flags that subdivide the privileges root has which is potentially an improvement over what we had before but it's nothing like the real capability-based security

https://en.wikipedia.org/wiki/Capability-based_security

that you had in AS/400 or the iAPX 432 where a "capability" is a reference to a system object with associated privileges. It is possible to get this into a POSIX-like system

https://en.wikipedia.org/wiki/Capsicum_(Unix)

It reminds me of using a VAX-11/730 with the VMS operating system in high school where there was a long list of privileges a process could have

https://hunter.goatley.com/vax-professional-articles/vax-pro...

and it was a common game to investigate paths such as "if you have privilege A, B, and C you can get SETPRV and take over the machine"

replies(3): >>45670909 #>>45673562 #>>45674752 #
1. btilly ◴[22 Oct 25 20:29 UTC] No.45674752[source]▶
In particular the big win with a true capability system is avoiding the confused deputy problem. True capability systems avoid it by always associating the action to be taken, with the reason why you should be able to take it. And so a deputy who acts on behalf of A and B, cannot accidentally take an action for A using a permission from B.

But Linux "capabilities" do not address this. If you have the permission, you have the permission. And can do the action. Even if the reason why you are trying to do the action (needed for A's request) doesn't match the reason that you are able do it (needed to do things for B).