5 ms·

Without the support of the OS, what are some examples of regular software (multiuser webapps... etc) using the capability design. And does this imply that the c

Without the support of the OS, what are some examples of regular software (multiuser webapps... etc) using the capability design. And does this imply that the capability design only works internally and you cannot pass caps to other applications?

nickpsecurity 9y ago
Note that I'm answering your question with two examples that would and might be considered OS's because they themselves had to implement the capability model in generic ways and with principles you might find useful in non-OS work. Especially with prevalence of things like containers, browsers, and full-on interpreters that are like mini-OS's. I have some non-OS examples, though. KeyKOS/KeySAFE was a whole, capability-based platform designed for high-security: http://www.cap-lore.com/Agorics/Library/KeyKos/keysafe/Keysafe.html http://www.cap-lore.com/Agorics/Library/KeyKos/keysafe/Keysa... Rees did a security kernel for Scheme48: http://mumble.net/~jar/pubs/secureos/secureos.html http://mumble.net/~jar/pubs/secureos/secureos.html Waterkin server for web apps done with capability-secure version of Java: http://waterken.sourceforge.net http://waterken.sourceforge.net DarpaBrowser was written in E language: http://www.combex.com/tech/darpaBrowser.html http://www.combex.com/tech/darpaBrowser.html Pony is used for Wallaroo. It presumably uses reference capabilities: https://blog.wallaroolabs.com/2017/10/why-we-used-pony-to-write-wallaroo/ https://blog.wallaroolabs.com/2017/10/why-we-used-pony-to-wr... https://tutorial.ponylang.org/capabilities/reference-capabilities.html https://tutorial.ponylang.org/capabilities/reference-capabil... Edited to add Cap n Proto for IPC. Thanks kentonv for reminder. Should not have forgotten! https://capnproto.org https://capnproto.org
kentonv 9y ago
Lots and lots of software uses aspects of capability design internally, sometimes intentionally, sometimes by accident. In particular, many IPC mechanisms that involve more than a few parties interacting -- especially when some or all parties are intended to be sandboxed -- become capability systems. Examples of real-world capability systems include: - Android's Binder - Chrome's Mojo - FreeBSD's Capsicum - Linux's Bus1 (not yet merged into mainline) - Classical Unix domain sockets (in that you can pass a file descriptor over a socket). - Cap'n Proto RPC, especially as used in Sandstorm.io (disclosure: these are my creations) - The Google Docs "anyone with the link can access" mode and e-mail invitations to non-Google accounts (this is a relatively weak and unintentional capability system). - OAuth 2's use of bearer tokens (also relatively weak). > does this imply that the capability design only works internally and you cannot pass caps to other applications? It's best if the applications agree on a capability protocol, but in some cases you can trick applications into behaving in a capability-based way without explicit support. For example, using secret, unguessable URLs can allow for capability-like design patterns -- although at the risk that secret URLs are relatively easy to leak (stronger capability systems can protect against accidental leakage).
- b1daly 9y ago
  Struggling to get my mind around this. One system I’m familiar with that comes to mind is the Drupal CMS “permissions” system. You can set content types, and along with associated fields. There are things you can do: view a resource (in practice a page or a particular field of a page), edit a resource, or create/delete a resource. Users are assigned “roles” which are then given permission to do certain things on various resources. It looks like a big grid, with all possible actions as rows, and the various roles along the top as columns. Users are assigned a role, which then limits what they can see/do on a website. This seems sort of akin to capabilities, but not quite. For one thing, there is no easy way to set up the permissions for a single object, which you could then assign to a given user. To get that level of granularity you would have to create a new “role” and a new object type.
  - kpreid 9y ago
    A capability system is sort of like having lots and lots of those roles. But a key element is that within the system you don't have to be an administrator or have any kind of privileged-operation access to create a new capability, you just do it, and then you can pass it around (loosely equivalent to giving the role to others). Capability systems include a way to _pass_ capabilities as part of the basic routine operations.
  - kentonv 9y ago
    What you describe is not capabilities. If you have a table mapping user identities to roles, that's an ACL, not a capability system. So what does a capability system look like? Before I describe, note: I don't necessarily recommend exposing pure capabilities in a UI for end users. Capabilities are an implementation technique, but can be used to build a user interface that behaves like ACLs from the user's perspective. You'll find, though, that once you've built your underlying system on capabilities, it's much easier to add useful features to your high-level sharing UI that go beyond what can be easily represented with ACLs. For example, it's easier to add secure delegation. With that out of the way, what would a pure capability system look like, if we exposed it directly in a user interface? Let's say you want to give access to Bob. In a pure capability system, you don't assign a role to "Bob". Instead, you create a capability for the role, and you send that capability to Bob, via some arbitrary communications mechanism. Bob uses the capability, which grants him access. Crucially, there is no need for the system to have any notion of how to authenticate "Bob". It doesn't care if the user is really "Bob", it only cares that the user presents the correct capability. This is where capability systems are powerful -- they avoid the need for any centralized list of principals (user identities) and avoid the need for a way to authenticate those principals. This is especially helpful when you need to, say, delegate some responsibility to an automated system that shouldn't be treated as a full user. But does this mean that when someone accesses the capability, the system actually has no idea who they are, and so can't attribute the changes to anyone? No. In a capability system, we can take a different approach to auditability. When you create a capability to send to Bob, you can arrange so that any actions performed using the capability are logged as, e.g., "via Bob". Note that this may be a mere text string. The system still doesn't need to know what "Bob" means, but you can now see in the logs which actions were done by Bob. If Bob further delegates his capability to Carol, he may want to add a second label, "via Carol". Now when you look at the logs, you might see "via Bob; via Carol". This means: "Bob claims that Carol performed this action." No one other than Bob actually needs to know who "Carol" is, much less how to authenticate her. Carol could very well be Bob's imaginary friend. Since the assertion in the audit log says "via Bob" first, we know to hold Bob responsible first. We only care about Carol to the extent that we trust Bob. Now, again, I don't actually endorse creating a UX like this, because not many users are equipped to understand it. But if you think about it, it does emulate real-life interactions. If I lend my car to Bob, and then the car ends up crashed, I will blame Bob. Bob can say "Oh, I lent it to my friend Carol, she was the one who crashed it," but I don't care, I'm going to hold Bob responsible. At no point in this process do I need to check Bob or Carol's government-issued ID to find out who really crashed my car.
thingification 9y ago
I'm surprised nobody else mentioned Google Caja.

nickpsecurity 9y ago

Note that I'm answering your question with two examples that would and might be considered OS's because they themselves had to implement the capability model in generic ways and with principles you might find useful in non-OS work. Especially with prevalence of things like containers, browsers, and full-on interpreters that are like mini-OS's. I have some non-OS examples, though. KeyKOS/KeySAFE was a whole, capability-based platform designed for high-security: http://www.cap-lore.com/Agorics/Library/KeyKos/keysafe/Keysafe.html http://www.cap-lore.com/Agorics/Library/KeyKos/keysafe/Keysa... Rees did a security kernel for Scheme48: http://mumble.net/~jar/pubs/secureos/secureos.html http://mumble.net/~jar/pubs/secureos/secureos.html Waterkin server for web apps done with capability-secure version of Java: http://waterken.sourceforge.net http://waterken.sourceforge.net DarpaBrowser was written in E language: http://www.combex.com/tech/darpaBrowser.html http://www.combex.com/tech/darpaBrowser.html Pony is used for Wallaroo. It presumably uses reference capabilities: https://blog.wallaroolabs.com/2017/10/why-we-used-pony-to-write-wallaroo/ https://blog.wallaroolabs.com/2017/10/why-we-used-pony-to-wr... https://tutorial.ponylang.org/capabilities/reference-capabilities.html https://tutorial.ponylang.org/capabilities/reference-capabil... Edited to add Cap n Proto for IPC. Thanks kentonv for reminder. Should not have forgotten! https://capnproto.org https://capnproto.org

kentonv 9y ago

Lots and lots of software uses aspects of capability design internally, sometimes intentionally, sometimes by accident. In particular, many IPC mechanisms that involve more than a few parties interacting -- especially when some or all parties are intended to be sandboxed -- become capability systems. Examples of real-world capability systems include: - Android's Binder - Chrome's Mojo - FreeBSD's Capsicum - Linux's Bus1 (not yet merged into mainline) - Classical Unix domain sockets (in that you can pass a file descriptor over a socket). - Cap'n Proto RPC, especially as used in Sandstorm.io (disclosure: these are my creations) - The Google Docs "anyone with the link can access" mode and e-mail invitations to non-Google accounts (this is a relatively weak and unintentional capability system). - OAuth 2's use of bearer tokens (also relatively weak). > does this imply that the capability design only works internally and you cannot pass caps to other applications? It's best if the applications agree on a capability protocol, but in some cases you can trick applications into behaving in a capability-based way without explicit support. For example, using secret, unguessable URLs can allow for capability-like design patterns -- although at the risk that secret URLs are relatively easy to leak (stronger capability systems can protect against accidental leakage).

b1daly 9y ago
Struggling to get my mind around this. One system I’m familiar with that comes to mind is the Drupal CMS “permissions” system. You can set content types, and along with associated fields. There are things you can do: view a resource (in practice a page or a particular field of a page), edit a resource, or create/delete a resource. Users are assigned “roles” which are then given permission to do certain things on various resources. It looks like a big grid, with all possible actions as rows, and the various roles along the top as columns. Users are assigned a role, which then limits what they can see/do on a website. This seems sort of akin to capabilities, but not quite. For one thing, there is no easy way to set up the permissions for a single object, which you could then assign to a given user. To get that level of granularity you would have to create a new “role” and a new object type.
- kpreid 9y ago
  A capability system is sort of like having lots and lots of those roles. But a key element is that within the system you don't have to be an administrator or have any kind of privileged-operation access to create a new capability, you just do it, and then you can pass it around (loosely equivalent to giving the role to others). Capability systems include a way to _pass_ capabilities as part of the basic routine operations.
- kentonv 9y ago
  What you describe is not capabilities. If you have a table mapping user identities to roles, that's an ACL, not a capability system. So what does a capability system look like? Before I describe, note: I don't necessarily recommend exposing pure capabilities in a UI for end users. Capabilities are an implementation technique, but can be used to build a user interface that behaves like ACLs from the user's perspective. You'll find, though, that once you've built your underlying system on capabilities, it's much easier to add useful features to your high-level sharing UI that go beyond what can be easily represented with ACLs. For example, it's easier to add secure delegation. With that out of the way, what would a pure capability system look like, if we exposed it directly in a user interface? Let's say you want to give access to Bob. In a pure capability system, you don't assign a role to "Bob". Instead, you create a capability for the role, and you send that capability to Bob, via some arbitrary communications mechanism. Bob uses the capability, which grants him access. Crucially, there is no need for the system to have any notion of how to authenticate "Bob". It doesn't care if the user is really "Bob", it only cares that the user presents the correct capability. This is where capability systems are powerful -- they avoid the need for any centralized list of principals (user identities) and avoid the need for a way to authenticate those principals. This is especially helpful when you need to, say, delegate some responsibility to an automated system that shouldn't be treated as a full user. But does this mean that when someone accesses the capability, the system actually has no idea who they are, and so can't attribute the changes to anyone? No. In a capability system, we can take a different approach to auditability. When you create a capability to send to Bob, you can arrange so that any actions performed using the capability are logged as, e.g., "via Bob". Note that this may be a mere text string. The system still doesn't need to know what "Bob" means, but you can now see in the logs which actions were done by Bob. If Bob further delegates his capability to Carol, he may want to add a second label, "via Carol". Now when you look at the logs, you might see "via Bob; via Carol". This means: "Bob claims that Carol performed this action." No one other than Bob actually needs to know who "Carol" is, much less how to authenticate her. Carol could very well be Bob's imaginary friend. Since the assertion in the audit log says "via Bob" first, we know to hold Bob responsible first. We only care about Carol to the extent that we trust Bob. Now, again, I don't actually endorse creating a UX like this, because not many users are equipped to understand it. But if you think about it, it does emulate real-life interactions. If I lend my car to Bob, and then the car ends up crashed, I will blame Bob. Bob can say "Oh, I lent it to my friend Carol, she was the one who crashed it," but I don't care, I'm going to hold Bob responsible. At no point in this process do I need to check Bob or Carol's government-issued ID to find out who really crashed my car.

thingification 9y ago

I'm surprised nobody else mentioned Google Caja.