3 ms·

My experience with this on Plan 9 (while not an object-capability operating system, it gets IMO most of the way there in the ways that matter in order to experi

by nrr 2y ago

My experience with this on Plan 9 (while not an object-capability operating system, it gets IMO most of the way there in the ways that matter in order to experiment) was that it worked a treat for long-running services, but it was a little hard to make ergonomic for the end user sitting at a terminal. I played with augmenting factotum with a form of mandatory access control, whereby I could ask the hostowner's factotum to mount and bind things into a freshly rfork()'d namespace on an as-needed basis, but the feeling was that it could build up access delegation fatigue pretty quickly.

kragen 2y ago
plan9 is a very inspiring system but its security model is in no way similar to the object-capability model. well, one way: it has file descriptors. but can you even pass a file descriptor across a file descriptor in plan9 the way scm_rights lets you do in bsd and linux? plash did get a reasonably ergonomic pola shell working under linux, but unfortunately it has bitrotted. fundamentally the insight is that most of the time when you want a process to open a file you have to tell it which file to open. if you give it an open file descriptor instead of a string, it doesn't need the authority to open existing files itself. just one step further down the path where the shell does the globbing, not the program launched in theory you could do the same thing with per-process filesystem namespaces as you are describing, but it seems like it would take a lot more work to make it reliable and usable
- nrr 2y ago
  "but can you even pass a file descriptor across a file descriptor in plan9 the way scm_rights lets you do in bsd and linux?" No, the mechanism was even simpler. We had the #s device (usually bound as /srv) for this, whereby you could drop a file in /srv containing a single integer representing a file descriptor, and other processes could open() that file to get another reference to that file descriptor. My mandatory access control experiments abused the fact that I could have open file descriptors and barely anything bound in the namespace by the time I exec()ed what I wanted to run. What files did those file descriptors reference? You didn't need to know, and you couldn't see them.
  - kragen 2y ago
    thanks for explaining! that sounds like, as long as the confined process couldn't mount more devices, it could definitely work, with a whole new set of core utilities that looked at predetermined filenames in the filesystem rather than taking filenames on the command line the #s mechanism sounds considerably less horrific than scm_rights
    - nrr 2y ago
      Yeah, that was the subtext that I left unsaid through this. rfork(RFNOMNT|RFCNAMEG) got you both a completely clean namespace and a namespace that denied additional mounts (as well as dereferencing pathnames beginning with #, as in #s). The Plan 9 primitives were refreshingly simple and consistent.
      - kragen 2y ago
        i see, thanks! were you working at cisco at the time? i remember they were having a hard time sourcing video cards with plan9 support because nobody had added pci video card support to it yet i feel like plan9 still tends to pass a lot of ambient authority to new processes by default
        nrr 2y ago
        No, I've never worked for Cisco, but I did have my own firewall product at one point. (: That's another story for another day though. Plan 9 is, at its core, still an ambient authority system, and I will never try to misrepresent it otherwise. That said, I've found it does an admirable job emulating what a "familiar" (in the sense of not looking completely alien to someone who only knows ambient authority) object-capability system could look like, kind of like how you can emulate the free monad in Ruby despite it not being a functional programming language. This is possible principally because the mantra of Plan 9 is that everything is a filesystem: if you can bind it into your namespace, you can access it. As a corollary, if you can't bind it into your namespace, you can't access it. It makes shaping one's ambient authority a remarkably productive endeavor.

by nrr 2y ago

kragen 2y ago

plan9 is a very inspiring system but its security model is in no way similar to the object-capability model. well, one way: it has file descriptors. but can you even pass a file descriptor across a file descriptor in plan9 the way scm_rights lets you do in bsd and linux? plash did get a reasonably ergonomic pola shell working under linux, but unfortunately it has bitrotted. fundamentally the insight is that most of the time when you want a process to open a file you have to tell it which file to open. if you give it an open file descriptor instead of a string, it doesn't need the authority to open existing files itself. just one step further down the path where the shell does the globbing, not the program launched in theory you could do the same thing with per-process filesystem namespaces as you are describing, but it seems like it would take a lot more work to make it reliable and usable

nrr 2y ago
"but can you even pass a file descriptor across a file descriptor in plan9 the way scm_rights lets you do in bsd and linux?" No, the mechanism was even simpler. We had the #s device (usually bound as /srv) for this, whereby you could drop a file in /srv containing a single integer representing a file descriptor, and other processes could open() that file to get another reference to that file descriptor. My mandatory access control experiments abused the fact that I could have open file descriptors and barely anything bound in the namespace by the time I exec()ed what I wanted to run. What files did those file descriptors reference? You didn't need to know, and you couldn't see them.
- kragen 2y ago
  thanks for explaining! that sounds like, as long as the confined process couldn't mount more devices, it could definitely work, with a whole new set of core utilities that looked at predetermined filenames in the filesystem rather than taking filenames on the command line the #s mechanism sounds considerably less horrific than scm_rights
  - nrr 2y ago
    Yeah, that was the subtext that I left unsaid through this. rfork(RFNOMNT|RFCNAMEG) got you both a completely clean namespace and a namespace that denied additional mounts (as well as dereferencing pathnames beginning with #, as in #s). The Plan 9 primitives were refreshingly simple and consistent.
    - kragen 2y ago
      i see, thanks! were you working at cisco at the time? i remember they were having a hard time sourcing video cards with plan9 support because nobody had added pci video card support to it yet i feel like plan9 still tends to pass a lot of ambient authority to new processes by default
      - nrr 2y ago
        No, I've never worked for Cisco, but I did have my own firewall product at one point. (: That's another story for another day though. Plan 9 is, at its core, still an ambient authority system, and I will never try to misrepresent it otherwise. That said, I've found it does an admirable job emulating what a "familiar" (in the sense of not looking completely alien to someone who only knows ambient authority) object-capability system could look like, kind of like how you can emulate the free monad in Ruby despite it not being a functional programming language. This is possible principally because the mantra of Plan 9 is that everything is a filesystem: if you can bind it into your namespace, you can access it. As a corollary, if you can't bind it into your namespace, you can't access it. It makes shaping one's ambient authority a remarkably productive endeavor.