5 ms·

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 hav

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.

rootnod3 1y ago
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.
- hypeatei 1y ago
  OpenBSDs pledge is so simple and nice to use. I really wish Linux would incorporate it. Seccomp is a nightmare to implement.
  - rootnod3 1y ago
    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.
  - eikenberry 1y ago
    There is a port... https://github.com/jart/pledge https://justine.lol/pledge/
    - hypeatei 1y ago
      That uses seccomp under the hood and requires a custom libc, I think? Definitely a nice project, but I don't know if I'd use it in production.
- charcircuit 1y ago
  I disagree. Pledge requires every app to OPT IN to security. This means that most apps won't do it, and the ones that do will likely be lazy and restrict their usage to what they use before and won't do the work of rearchitecting things.
  - hypeatei 1y ago
    So we shouldn't provide simple hardening tools because it won't be used or applied how you'd like in 100% of software? This mindset in security circles really needs to stop. If a piece of important or foundational software wants to lock itself down today, look at the myriad of convoluted "solutions" mentioned in a sibling comment. If you wanted to discourage progress in this area, that's how you'd design something. I'm not assuming malice, obviously, but it's certainly a product of the endless nitpicking and "not good enough, doesn't cover <niche usecase>" type of thinking. EDIT: > and the ones that do will likely be lazy I'd argue the opposite, any developer taking the time to add some pledge calls to their code is probably mindful of security and wants to improve it. If you wanted to be lazy, you'd just... not implement pledge at all since it'd get in your way and be too restrictive.
    - charcircuit 1y ago
      It's not that we shouldn't provide it, but it doesn't make sense invest into when OpenBSDs security is so far behind the rest of the industry. A program being able to steal your .ssh keys without you knows is unacceptable. Not only that but programs can keylog you, take pictures of what you are doing, or take remote control of your computer.
      - munchlax 1y ago
        I doubt you could keylog my openbsd server that I remote into over ssh or serial. I also doubt you can take pictures of me when it doesn't have cameras attached. If it did and you were to take pictures, you'd see some blinking leds and cables all day. And I highly doubt you could take remote control even if I had openssh open to the public. Perhaps your industry just doesn't care about the same things the openbsd community does. Edit: I missed the ssh key stealing. My keys are always encrypted.
PaulHoule 1y 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 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) 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-09/ 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"
- nullpoint420 1y ago
  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.
- FuriouslyAdrift 1y ago
  You can get there most of the way with SeL4 and CHERI.
- btilly 1y ago
  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).
monocasa 1y ago
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.
candiddevmike 1y ago
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.
- shwaj 1y ago
  Fuchsia pervasively uses capabilities.
marcosdumay 1y ago
> whereby children can only be given access to capabilities their parents have The one thing that makes capabilities usable is that they don't need to follow that rule. If you don't have processes that let your programs get capabilities from any source other than their creation, you are better just adding your program names into your ACLs.
ori_b 1y ago
Note that namespaces are effectively capabilities.

rootnod3 1y ago

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.

hypeatei 1y ago
OpenBSDs pledge is so simple and nice to use. I really wish Linux would incorporate it. Seccomp is a nightmare to implement.
- rootnod3 1y ago
  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.
- eikenberry 1y ago
  There is a port... https://github.com/jart/pledge https://justine.lol/pledge/
  - hypeatei 1y ago
    That uses seccomp under the hood and requires a custom libc, I think? Definitely a nice project, but I don't know if I'd use it in production.
charcircuit 1y ago
I disagree. Pledge requires every app to OPT IN to security. This means that most apps won't do it, and the ones that do will likely be lazy and restrict their usage to what they use before and won't do the work of rearchitecting things.
- hypeatei 1y ago
  So we shouldn't provide simple hardening tools because it won't be used or applied how you'd like in 100% of software? This mindset in security circles really needs to stop. If a piece of important or foundational software wants to lock itself down today, look at the myriad of convoluted "solutions" mentioned in a sibling comment. If you wanted to discourage progress in this area, that's how you'd design something. I'm not assuming malice, obviously, but it's certainly a product of the endless nitpicking and "not good enough, doesn't cover <niche usecase>" type of thinking. EDIT: > and the ones that do will likely be lazy I'd argue the opposite, any developer taking the time to add some pledge calls to their code is probably mindful of security and wants to improve it. If you wanted to be lazy, you'd just... not implement pledge at all since it'd get in your way and be too restrictive.
  - charcircuit 1y ago
    It's not that we shouldn't provide it, but it doesn't make sense invest into when OpenBSDs security is so far behind the rest of the industry. A program being able to steal your .ssh keys without you knows is unacceptable. Not only that but programs can keylog you, take pictures of what you are doing, or take remote control of your computer.
    - munchlax 1y ago
      I doubt you could keylog my openbsd server that I remote into over ssh or serial. I also doubt you can take pictures of me when it doesn't have cameras attached. If it did and you were to take pictures, you'd see some blinking leds and cables all day. And I highly doubt you could take remote control even if I had openssh open to the public. Perhaps your industry just doesn't care about the same things the openbsd community does. Edit: I missed the ssh key stealing. My keys are always encrypted.

PaulHoule 1y 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 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) 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-09/ 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"

nullpoint420 1y ago
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.
FuriouslyAdrift 1y ago
You can get there most of the way with SeL4 and CHERI.
btilly 1y ago
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).

monocasa 1y ago

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.

candiddevmike 1y ago

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.

shwaj 1y ago
Fuchsia pervasively uses capabilities.

marcosdumay 1y ago

> whereby children can only be given access to capabilities their parents have The one thing that makes capabilities usable is that they don't need to follow that rule. If you don't have processes that let your programs get capabilities from any source other than their creation, you are better just adding your program names into your ACLs.

ori_b 1y ago

Note that namespaces are effectively capabilities.