Linux Capabilities Revisited
dfir.ch
Linux Capabilities Revisited
1–10 of 43 posts
Re: Linux Capabilities Revisited
#2A 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.
Re: Linux Capabilities Revisited
#3A 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 hierar…
Even if not super fine grained, I think that OpenBSD’s pledge is really nicely done.
Next after that I’d vote for FreeBSD’s capsicum.
Re: Linux Capabilities Revisited
#4A 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 hierar…
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"
Re: Linux Capabilities Revisited
#5Fascinating, thank you for sharing.
Re: Linux Capabilities Revisited
#6A 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 hierar…
Even if not super fine grained, I think that OpenBSD’s pledge is really nicely done. Next after that I’d vote for FreeBSD’s capsicum.
OpenBSDs pledge is so simple and nice to use. I really wish Linux would incorporate it. Seccomp is a nightmare to implement.
Re: Linux Capabilities Revisited
#7A 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 hierar…
Linux capabilities are fairly unrelated to the traditional concept of object capability based security.
They're closer to apple entitlements, but inherited through through forks rather than being attached to a binary.
Re: Linux Capabilities Revisited
#8A 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 hierar…
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 htt…
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.
Re: Linux Capabilities Revisited
#9Earlier quoted context omitted.
Even if not super fine grained, I think that OpenBSD’s pledge is really nicely done. Next after that I’d vote for FreeBSD’s capsicum.
OpenBSDs pledge is so simple and nice to use. I really wish Linux would incorporate it. Seccomp is a nightmare to implement.
I'd rather have a simple coarse-grained mechanism than whatever feverdream that seccomp, selinux and apparmor are. A convoluted mess incorporating almost Turing complete languages that are just asking to shoot yourself in the foot a mile deep.
The simplicity of pledge is good enough for 99% of use-cases I'd wager AND easy to add to existing code.
Re: Linux Capabilities Revisited
#10A 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 hierar…
I don't think you can bolt something like what you're describing onto an existing kernel (like linux did with capabilities). You'd have to design it this way from the ground up. I think I've read about some experimental OSs exploring that kind of capability by design, almost like a type 1 hypervisor but for processes.