Hacker News new | ask | show | jobs
by PaulHoule 233 days ago
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"

3 comments

A very similar process happens in security research for macOS and iOS w/ the mach kernel. Researchers look for open mach ports that are ripe for privilege escalation.
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).

You can get there most of the way with SeL4 and CHERI.