3 ms·

I don't disagree that the prevailing ambient authority model is less than ideal, but I'm left scratching my head at how capability security would solve the more

by nrr 2y ago

I don't disagree that the prevailing ambient authority model is less than ideal, but I'm left scratching my head at how capability security would solve the more acute problem we're facing. Of particular note, the kinds of ransomware compromise that lead to organizations asking underwriters to sell them cybersecurity insurance policies wouldn't immediately be thwarted by moving to capabilities. If a principal has valid requisite pointers to the resources they need to do their job, they have valid requisite pointers to the resources that a cryptolocker needs to cause disaster. It's those cybersecurity insurance policies (or regulatory frameworks, where those exist) that ultimately drive the decisions to implement EDRs.

mikewarot 2y ago
Who would trust the code that the ransomware sneaks use with all of the resources of their system? You can hand $5 over to someone without risking your life savings, surely you could do the same to hand over a temporary folder to run a random piece of code from the internet, and not your full administrator credentials. Capabilities change things in a profound way. They make it trivial to run any old code, yet not have to ever trust it.
- nrr 2y ago
  The thing that still puzzles me is how we determine which workload gets which capabilities. On Plan 9, I took a lot of glee in rfork()ing my way into a tightly curated namespace that disallowed subsequent use of mount and bind, but that was a deliberate decision under the philosophy of the principle of least privilege. Is that the other half of what you're after?
  - mikewarot 2y ago
    Unlike money in a wallet, capabilities can be composed. You can take an existing capability, and tack a filter onto it, and use that composed capability. For example, you need to do backups. Take the system administrator's access to everything, but put it through a read-only filter, and pass that to the backup program. Instead of using the "File Open" dialog in the Win32 gui api... and then a "file open" which could go anywhere, replace it with a call to the file-open "powerbox", which hands a file back to the application. The user could even make it read only, append only, etc. As far as users are concerned, it doesn't have to be hard. We just have to learn some new command line tricks.
    - nrr 2y ago
      Right. On Plan 9, this kind of composition usually took the form of rfork()ing to inherit the parent process's namespace, mutating it in a handful of ways deemed useful, and then exec()ing the new image. The mechanics are clear to me, I feel. What isn't clear are the logistics: what, concretely, do we need to undertake in order to avoid a security posture lateral step from ambient authority to object-capabilities? Importantly, how do we make this ergonomic?
      - mikewarot 2y ago
        Doing it in a GUI should be fairly trivial, it's just update/replacement of the file pickers with a few more options. As far as the command line goes... that's the problem. We don't have any standardization for command line syntax. My first instinct is to try to impose it, but that seems like a "boil the ocean" approach. Next up, something like pipes? Maybe a new set of delimiters to pipe capabilities, and allow testing of them in some fairly transparent way? Let's say that ||| pipes a capability $ select / ||| showcaps showcaps: / - FULL ACCESS $ select / ||| readonly ||| showcaps showcaps: / - READ ONLY I'm sure they had something figured out for KeyKOS etc, I don't know what that was.
        nrr 2y ago
        I strongly suspect that a good GUI implementation will look like how file choosers on RISC OS work, and the command line environment might be inspired by both Plan 9's namespaces and how data definitions (and their accompanying data control blocks) work in JES2 JCL on MVS. My only concern is that, without well-thought-out access controls, the only people who will care will be nerds or folks with a high frustration tolerance for poorly-considered human-computer interaction.
kragen 2y ago
object-capabilities grant access to running processes rather than to human principals
- nrr 2y ago
  Sorry, I was imprecise. If a principal starts a new process that indiscriminately inherits the same capabilities of its parent, the security posture is no different from what we have today.
  - kragen 2y ago
    right, and not doing that is about 70% of what object-capability security is all about. the other 30% is avoiding confused-deputy attacks
    - 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

by nrr 2y ago

mikewarot 2y ago

Who would trust the code that the ransomware sneaks use with all of the resources of their system? You can hand $5 over to someone without risking your life savings, surely you could do the same to hand over a temporary folder to run a random piece of code from the internet, and not your full administrator credentials. Capabilities change things in a profound way. They make it trivial to run any old code, yet not have to ever trust it.

nrr 2y ago
The thing that still puzzles me is how we determine which workload gets which capabilities. On Plan 9, I took a lot of glee in rfork()ing my way into a tightly curated namespace that disallowed subsequent use of mount and bind, but that was a deliberate decision under the philosophy of the principle of least privilege. Is that the other half of what you're after?
- mikewarot 2y ago
  Unlike money in a wallet, capabilities can be composed. You can take an existing capability, and tack a filter onto it, and use that composed capability. For example, you need to do backups. Take the system administrator's access to everything, but put it through a read-only filter, and pass that to the backup program. Instead of using the "File Open" dialog in the Win32 gui api... and then a "file open" which could go anywhere, replace it with a call to the file-open "powerbox", which hands a file back to the application. The user could even make it read only, append only, etc. As far as users are concerned, it doesn't have to be hard. We just have to learn some new command line tricks.
  - nrr 2y ago
    Right. On Plan 9, this kind of composition usually took the form of rfork()ing to inherit the parent process's namespace, mutating it in a handful of ways deemed useful, and then exec()ing the new image. The mechanics are clear to me, I feel. What isn't clear are the logistics: what, concretely, do we need to undertake in order to avoid a security posture lateral step from ambient authority to object-capabilities? Importantly, how do we make this ergonomic?
    - mikewarot 2y ago
      Doing it in a GUI should be fairly trivial, it's just update/replacement of the file pickers with a few more options. As far as the command line goes... that's the problem. We don't have any standardization for command line syntax. My first instinct is to try to impose it, but that seems like a "boil the ocean" approach. Next up, something like pipes? Maybe a new set of delimiters to pipe capabilities, and allow testing of them in some fairly transparent way? Let's say that ||| pipes a capability $ select / ||| showcaps showcaps: / - FULL ACCESS $ select / ||| readonly ||| showcaps showcaps: / - READ ONLY I'm sure they had something figured out for KeyKOS etc, I don't know what that was.
      - nrr 2y ago
        I strongly suspect that a good GUI implementation will look like how file choosers on RISC OS work, and the command line environment might be inspired by both Plan 9's namespaces and how data definitions (and their accompanying data control blocks) work in JES2 JCL on MVS. My only concern is that, without well-thought-out access controls, the only people who will care will be nerds or folks with a high frustration tolerance for poorly-considered human-computer interaction.

kragen 2y ago

object-capabilities grant access to running processes rather than to human principals

nrr 2y ago
Sorry, I was imprecise. If a principal starts a new process that indiscriminately inherits the same capabilities of its parent, the security posture is no different from what we have today.
- kragen 2y ago
  right, and not doing that is about 70% of what object-capability security is all about. the other 30% is avoiding confused-deputy attacks
  - 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