8 ms·

What Are Capabilities?

134 points by abecedarius 9y ago

tzahola 9y ago
What prevents capability based security models from widespread adoption? Is it again the fault of UNIX being “not bad enough”?
- urbit 9y ago
  This is a great question. One possible answer: maybe the right system would use "ambient authority" (ACLs, etc) for the common case, but scale up to true capabilities for interesting corner cases. Creating capability UIs that compete, in the common case, with the normal ambient-authority design, is ferociously hard. This seems to be where most capability systems falter. The hardest UI problem in the leading modern capability OS, Sandstorm, is certainly the capability "powerbox." Think about all the places you can type a filename or a URL. If the designator and the authorization have to travel together, and the pair is an unforgeable capability, then user-entered designators (like paths or URLs) are not practical. Designators can't travel through unsecured paths, through the human mind, etc. This is a painful limitation. That said, the OP is the best explanation of capabilities I've ever seen. Everyone really should read it.
  - kentonv 9y ago
    > The hardest UI problem in the leading modern capability OS, Sandstorm, is certainly the capability "powerbox." Heh, I'm not sure I'd describe Sandstorm as "leading" anything right now, but thanks. :) I think Sandstorm made the problem more difficult for itself by not just trying to solve this UI problem, but trying to do it in a way that can be integrated into existing codebases that were never designed with capabilities in mind. This is the really difficult part: dealing with legacy code. The powerbox itself is otherwise "just a picker", a fairly straightforward concept. For example, the standard file-open dialog box in everyone's browser, when invoked from an upload button on a web site, is actually a powerbox: the web site itself is given no access to any files except the one that the user chooses, but the file-open dialog is able to see everything. But imagine trying to graft this approach onto an existing native app, that is used to being able to read the hard drive directly and already has its own custom file picker UI built in. You have to convince the developers of that app to remove their nice custom UI and instead invoke the system's UI. Moreover, when they invoke the file picker, they now don't get back a file name, but rather an already-open file descriptor. So their code has to be adjusted to not expect a name. This could be hard, depending on how the code is organized: maybe it uses a bunch of libraries that expect to open a file by name, etc. Sandstorm is trying to graft this model onto apps that are used to making HTTP API requests to each other directly. We had designs figured out to make this work, and even make most of the process look like an OAuth request, so that existing OAuth-based apps might not need to change very much... some of this is implemented, but mostly we just didn't get there before running out of money. (I am still working on it in my spare time, though!)
    - urbit 9y ago
      Protip: if no one's ahead of you, you're leading :-) This is a great answer. I think the impedance-mismatch question is a big part of the problem. Personally I prefer to boil the ocean rather than drowning in the impedance-mismatch tarpit. Both of these strategies are, of course, profoundly insane. It's true that a file-open dialog box easily becomes a powerbox. But of course, you are using the ambient authority of the user's login session to ascribe authority to the path that gets typed. So in a way it's the exception that proves the rule. And does a URL bar easily become a powerbox? What about a command-line shell? Perhaps we're both just agreeing that there is always trivial ambient authority, and the right way to scale up to nontrivial cases is a capability model. I just worry that when too many people discover the beautiful screwdriver that is capabilities, they decide that everything should be a screw. But the world has nails. It may even be true that the world should have nails. And then you find yourself pounding in nails with the butt of your screwdriver. Have you considered an ICO? Asking for a friend :-)
      - kentonv 9y ago
        I agree that capability people tend to get too extreme, and this tends to lead to failure. With Sandstorm we've tried to be more pragmatic, but still careful not to do anything that breaks the whole model in the long run. Whether or not the URL bar of a browser is a kind of powerbox depends on how extreme you want to get. In a pure capability model, yes, it would have to be. And hypertext would no longer be plain data -- it would be data with embedded capabilities (for each link), and would have to be transmitted via a protocol that can track capabilities. Obviously that kind of stuff, even though it would be amazingly powerful in a lot of ways, is not practical. :/ > Have you considered an ICO? Asking for a friend :-) People keep asking me that, often citing Urbit as an example to follow. :) At the moment I'm having too much fun at my day job building Cloudflare Workers (an unusually practical project by my standards!), and want to focus my outside-of-work time on coding Sandstorm rather than fundraising for it. In the future, who knows.
        urbit 9y ago
        If I can distill my objection to the pure capability model: there are two different statements of the capability manifesto, one strong and one weak. The weak capability position is that it should be possible to construct an opaque combination of designator and authority, ie, a capability. The strong capability position is that designator and authority must always follow the same path. So in the "pure capability model," you are actually subtracting a feature from the system. Now, of course, it's often the case that subtracting a feature makes a system better. But one needs to be really clear about confusing this with the positive virtues of just having capabilities. Also, while I agree that capabilities are really great (Arvo has a somewhat capability-like internal communication model), it's important to point out that (a) capability vs. identity is a duality; and (b) it's cheating to compare a good capability system to a bad identity system. For (a), note that identity systems can implement capability features like delegation and revocation; they just have to do it actively rather than passively. If I am willing to act as your deputy, I can delegate my power to act to you. Or some restricted subset thereof. Tell me what to do and I'll do it. For (b), if you put a decent capability system next to the Internet, a network whose identity model is a burning-tire dumpster fire. If your identity system actually works and makes sense, competing is harder for the capability design. I do think Urbit should have some kind of capability model. However, this has the feel of a 2.0 or even 3.0 feature. I hate to solve a problem until it is actually in my way. I feel we have come nowhere near the limits of the common case. A simple map from identity to privilege is certainly that. And while capability UIs may be doable, identity UIs are trivial. This would not be the first case of humans being funky, hence screwing up our elegant architectural logic. If you have a system software project and it can advance without being lashed to a company, definitely do it that way! It's always a poor fit -- they have to succeed on different timelines. One thing I know: once we all have personal servers, today's cloud will look pretty lame in retrospect...
  - EtDybNuvCu 9y ago
    Unforgeability can be weakened systematically to unguessability: https://capability.party/philosophy/2017/07/29/unforgeable-vs-unguessable.html https://capability.party/philosophy/2017/07/29/unforgeable-v... Unfortunately, the concept of "taming", where ambient-authority systems are used to implement functionality in capability-safe systems, is often a sad and frustrating path due to massive impedance mismatch. Like you say, paths are not caps, which means that capability-safe languages on UNIX-like systems are constantly dancing to tame the OS. As usual, it would be great if you made your VM cap-aware, so that we may eventually get over this hump.
    - abecedarius 9y ago
      It's worth noting that WebAssembly should go nicely with capability systems. Mark S. Miller started a thread on the mailing lists recently about making sure it stays that way.
- kentonv 9y ago
  My opinion, as the designer of Sandstorm, a capability-based server OS: Capabilities are not the way developers are used to thinking. It may be that if people got used to it, it would make sense -- or it may be that it's simply too complicated and most developers will never wrap their heads around it. I honestly don't really know which it is. In this respect, it feels a lot like functional programming (FP and capabilities are very different concepts, but are similar in that it takes a while to fully understand how to use them effectively). We do see capability systems appearing by accident all over the place. Unix file descriptors, for example, behave very much like capabilities. Once open() finishes successfully, all access checks are done -- they aren't repeated for every read() or write(). You now have a capability, and you can even send that capability to other processes (even running under different UIDs that wouldn't have permission to open the file directly) via Unix domain sockets. People who really get how to exchange file descriptors build some amazing systems with them (without ever realizing they're building capability systems). But, for some reason, most systems do not really try to take advantage of FD passing, and instead opt to do things like listen on a globally-accessible port and perform an authentication handshake on incoming connections. I guess this kind of design just seems more obvious to people? But often, as systems get more complex and involve more parties, they end up forced to use capability-ish designs, because ACL-based designs get intractable. OAuth's use of bearer tokens, for example, is very capability-ish, albeit not acknowledged as such, and a fairly primitive form of capabilities. This sort of design turns out to be necessary in large-scale systems. If people would learn capability theory before designing such systems, they'd probably be more secure and powerful.
  - im_down_w_otp 9y ago
    Well... Kenton, now you've now got my brain stirring on whether or not the perceived complexity & opacity of ocap is an artifact of how tightly it has bound itself to the concepts of OOP (as something of a personal character flaw I find OOP to be fairly obfuscating beyond trivial domains for whatever reason), and whether or not FP concepts applied to a similar domain as ocap might provide me with clarity in security design/implementation the same way FP gave me clarity in program design/implementation eventually. None of which I really have excess time to noodle about, but is now unavoidable. Thank you, sir.
- kmicklas 9y ago
  IMO Unix is plenty bad enough to warrant replacement but unfortunately its iron grip on computing dooms any good ideas like capabilities in the short to medium term (at least 10 years).
- gumby 9y ago
  A big one is the cost of defense against forgery. A capability is essentially an index or pointer into a table in kernel space (much like an FD as another poster mentioned). The traditional mitigation is to use hardware tagging and permit the tag bits to be set only via a privileged instruction, e.g. Multics. The x86 segmented memory model also allowed this, and I used this to build some experimental SUID memory-mapped the 1990s (you could call into them via special gates, but not read the instruction memory, for example). Although you those memory models are still supported on x86 for back compatibility I don’t believe they are particularly fast any more, unfortunately. Edit: The lowrisc (RISC v) folks are implementing tagged memory also btw
  - EtDybNuvCu 9y ago
    Capabilities are either unforgeable or unguessable, depending on your vantage point: https://capability.party/philosophy/2017/07/29/unforgeable-vs-unguessable.html https://capability.party/philosophy/2017/07/29/unforgeable-v...
  - kentonv 9y ago
    Seems like you're talking about hardware capabilities, which haven't really been tried seriously since Intel's iAPX 432 processor in the early 80's. It failed miserably due to horrible performance, but some argue that the performance could have been fixed had they been given a second shot at it. Modern capability systems don't rely on hardware support and performance issues aren't usually cited as a problem with capabilities. In fact, capabilities can often perform better than ACLs since ACLs tend to require performing an expensive access check on every operation.
    - eb3c90 9y ago
      Thought it worth pointing out that Cheri are giving hardware capabilities another go. http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
    - gumby 9y ago
      yes, I was talking about hardware tagging, else you can’t protect capabilities solely in user space. Intel had tagged memory in the 90’s era i960 as well and, as I edited my comment to mention (thanks to your comment!) several others including most recently RISC-V). IMHO the 432 had other structural problems and it wasn’t the tagging that killed it but it had enough problems that this is definitely not worth disagreeing about — perhaps that was indeed the straw that broke that camel’s back.
- eb3c90 9y ago
  They have got some adoption. Android security model is somewhat capability security based. However it is used in an insufficiently fine grained way. It does highlight some ways that it may not work if used for desktop, programs would just ask for large-grained capabilities (can I access all your pictures/files etc) and you get back to ambient style authority. I think expecting the user to be an intelligent judge of what capabilities a program needs, is not realistic. I think something like agoric auction of capabilities might force programs to provide useful features to get access to data, might work. I'm exploring it anyway.
  - abecedarius 9y ago
    Marc Stiegler suggested having a set of standard authority bundles for when you're installing more or less standard app types. (Of course this raises the question of getting to a standard designed with users' interests in mind.) Then an app wanting undue authority would have to incur the pain of getting users to install it in a special unusual way. (He made that suggestion back before Android etc. existed.) People are pretty OK at judging and tracking what to entrust other people with. This suggests the problem shouldn't be impossible, but that our interfaces don't map well to those familiar abilities.
    - jgtrosh 9y ago
      > Then an app wanting undue authority would have to incur the pain of getting users to install it in a special unusual way. Isn't that similar to getting people used to installing anything they find on the web on Windows and just pressing accept for everything? I'd say a viable system needs to explicitly address special authority and make users are of it as an important thing, but still within the normal course of UX, to keep the distinction meaningful. The current state of Android is in the other direction: it explicitly addresses authority for many accesses, but they're not fine grain enough; so apps ask for a lot, getting people used to accept early without having a clear idea of what the app will do in the future, making it cheap for the programmer to ask for many accesses.
      - thingification 9y ago
- deepnotderp 9y ago
  Most C and C++ programs won't work then due to the way programmers have built them.
- bsder 9y ago
  Performance, mostly. Operating systems have tweaked the performance of user->kernel transitions to the point that anything placed on that path represents massive degradation in performance. Until we start having to pay performance for security, no one is going to bother. Meltdown and Spectre are really the first security attacks that will require significant amounts of performance to mitigate. Once we get enough of those kinds of attacks, people will start being willing to trade performance for security.
  - kentonv 9y ago
    No, performance is not usually cited as a reason against capabilities. Capability-based authorization usually has near-negligible cost to evaluate -- certainly less than the cost of evaluating ACLs. The problem with capabilities is that you have to design your code differently to use them effectively.
EGreg 9y ago
Capabilities have the following downside vs ACLs: Someone can share them with someone else. ACLs can be thought of as server-side mechanisms to increase the "specificity" of capabilities. The typical capability that ACLs work with is "identity", ie "I have access to this account." The idea is that people won't be able to delegate fine grained capabilities to someone else without giving the broad capability (access to their whole netflix account etc.) Now, the downside of ACLs is that they're much harder to do in a distributed computing fashion. So instead of blockchains etc. you have to trust a certain backend, and that backend can lock you out or become compromised. Think of capabilities as client-side controlled access tokens and ACLs as server side controlled ones.
- kentonv 9y ago
  > Someone can share them with someone else. Delegation is a feature, not a bug, because: > the downside of ACLs is that they're much harder to do in a distributed computing fashion. That's because large-scale work almost always requires delegation. So using a system that tries to prevent delegation is really shooting yourself in the foot -- but it seems fine at first, as long as the system stays simple. You only run into trouble when things get complex, and the ACLs become completely impossible to manage, but by then it's too late to make a fundamental design change. Now, you might insist that in some cases, you really do need to prevent delegation. But it turns out ACLs don't really enforce this: I can always set up a proxy server that has my credentials and provides some API to another user, hence delegating my authority with whatever granularity I wish. No ACL system prevents that, hence no ACL system prevents delegation! Usually, what you really want is not to prevent delegation entirely, but rather to prevent accidental policy breaches. That is, you trust that people aren't maliciously trying to circumvent the rules, but you aren't sure that your users fully understand what the rules are or why they are in place. This especially comes up in compliance scenarios: HIPAA or ITAR restrictions might legally prohibit delegating some data, but the rules are so complicated that not every employee in your company understands them. So, you want to enforce some basic policy rules that prevent them from doing so. It turns out this is a UI problem, not a security problem. In either an ACL system or a capability system, it's easy to design a UI that prevents such user error, without the need to fundamentally change the underlying security architecture. But, we're too used to thinking of these compliance problems as something the basic security architecture should enforce, rather than as a UI problem. So we keep shooting ourselves in the feet.
eadmund 9y ago
My own favourite metaphor for capabilities is that they are like physical keys. If I have a key, I can easily go to a shop and make a copy of that key, and give it to someone else. That other person will have all the access to the things behind the lock that I have.
- kentonv 9y ago
  Yes, but note more advanced capability systems go beyond that. You should not only be able to give a friend a copy of your key, but also be able to revoke their copy at any time, without also revoking your own copy or any other copies you gave out. You should also be able to set things up so that your friends' usage of the key is logged where you can see it. Your friend, OTOH, cannot see the logs of your use. But if your friend makes another copy to give to a third party, both you and your friend can see the logs of that third party's access. And if you revoke your friend's access, the third party is transitively revoked as well. That is to say, it's a tree.
  - EtDybNuvCu 9y ago
    Indeed, a capability is like a smart key. But it's more flexible than that; capabilities can run arbitrary code, like a smart card. And since capabilities can manage references to other capabilities, really a capability is like a smart executable contract. This is precisely where "smart contract" comes from. I should probably write a blog post about this.
  - AgentME 9y ago
    Also, depending on the system, you could mint a copy of your key that can only access part of your locker. If your friend is really good at fooing widgets, you don't want to do it yourself, and you don't want to continually bring all of your heavy widgets to them, then you can make a copy of your key that can only access the part of your locker holding your widgets and give that to them so they can come by and foo your widgets for you. With this system, you don't have to trust your friend to not mess with the other contents of your locker. You don't have to trust them to not take the money or personal documents you have in the other part of your locker. Maybe you believe you fully trust this friend, but maybe you don't fully trust their key-handling. If you gave them a restricted key, and you think one of your personal documents is missing from your locker one day, then you can skip worrying about whether it was your friend that's responsible. If your friend loses their key one day (they misplaced it, or someone stole it from them), then you don't need to freak out and worry about your personal documents; it's only your widgets that are in danger. If someone knows that your friend is given a lot of unrestricted keys to people's lockers, they might be incentivized to try to steal/blackmail/threaten the friend for their keys so they can get to people's important documents; if it's known that the friend always requests restricted keys from people to foo their widgets, then an attacker who doesn't care about widgets isn't incentivized to try to attack the friend.
snvzz 9y ago
For a very simple explanation, look at the Genode Foundations book (free, available on their website)
loeg 9y ago
One interesting application of the idea of capabilities to an existing POSIX system is FreeBSD's Capsicum. (There is also a Linux port of Capsicum, but it has not been integrated into Torvalds' tree.) In Capsicum, capabilities are tracked on a per file descriptor basis. A typical program opens any input paths, restricts capabilities on open fds (including stdio), and then enters sandbox mode. Once the capability mode sandbox is entered, no additional capabilities can be granted, and filesystem access via absolute paths is revoked. (Sandbox mode programs are expected to access files they already have open, or to use relative accesses to walk file trees.) Erroneous system calls generate ECAPMODE or ENOTCAPABLE errors if they attempt to perform actions they do not have permission to do.
- Majora320 9y ago
  What prevents a Sandbox mode program from just using a chain of `··`s to access the root?
  - ithkuil 9y ago
    IIRC openat(2) honours the sandboxing rules
  - loeg 9y ago
    Access to ".." above the "root" of a given dirfd are disallowed in the sandbox. So for example, if you have an open dirfd with the LOOKUP capability when you enter the sandbox, you can access the following relative paths: ".", "./foo/bar", "./foo/.." But you cannot access these relative paths: "..", "./foo/../..", etc.
CMCDragonkai 9y ago
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).
hierophantos 9y ago
I have also made bulleted notes of this article a few months back: https://github.com/hierophantos/capable https://github.com/hierophantos/capable Talking to one of the "O-Cap Gang", Norm Hardy (http://www.cap-lore.com/CapTheory/ http://www.cap-lore.com/CapTheory/) a few weeks ago, he said, to the point of creating secure distributed computing architectures: "Object capabilities are not easy, but they're the only way I see forward." I'm biased to agree.

134 points by abecedarius 9y ago

What prevents capability based security models from widespread adoption? Is it again the fault of UNIX being “not bad enough”?

urbit 9y ago
This is a great question. One possible answer: maybe the right system would use "ambient authority" (ACLs, etc) for the common case, but scale up to true capabilities for interesting corner cases. Creating capability UIs that compete, in the common case, with the normal ambient-authority design, is ferociously hard. This seems to be where most capability systems falter. The hardest UI problem in the leading modern capability OS, Sandstorm, is certainly the capability "powerbox." Think about all the places you can type a filename or a URL. If the designator and the authorization have to travel together, and the pair is an unforgeable capability, then user-entered designators (like paths or URLs) are not practical. Designators can't travel through unsecured paths, through the human mind, etc. This is a painful limitation. That said, the OP is the best explanation of capabilities I've ever seen. Everyone really should read it.
- kentonv 9y ago
  > The hardest UI problem in the leading modern capability OS, Sandstorm, is certainly the capability "powerbox." Heh, I'm not sure I'd describe Sandstorm as "leading" anything right now, but thanks. :) I think Sandstorm made the problem more difficult for itself by not just trying to solve this UI problem, but trying to do it in a way that can be integrated into existing codebases that were never designed with capabilities in mind. This is the really difficult part: dealing with legacy code. The powerbox itself is otherwise "just a picker", a fairly straightforward concept. For example, the standard file-open dialog box in everyone's browser, when invoked from an upload button on a web site, is actually a powerbox: the web site itself is given no access to any files except the one that the user chooses, but the file-open dialog is able to see everything. But imagine trying to graft this approach onto an existing native app, that is used to being able to read the hard drive directly and already has its own custom file picker UI built in. You have to convince the developers of that app to remove their nice custom UI and instead invoke the system's UI. Moreover, when they invoke the file picker, they now don't get back a file name, but rather an already-open file descriptor. So their code has to be adjusted to not expect a name. This could be hard, depending on how the code is organized: maybe it uses a bunch of libraries that expect to open a file by name, etc. Sandstorm is trying to graft this model onto apps that are used to making HTTP API requests to each other directly. We had designs figured out to make this work, and even make most of the process look like an OAuth request, so that existing OAuth-based apps might not need to change very much... some of this is implemented, but mostly we just didn't get there before running out of money. (I am still working on it in my spare time, though!)
  - urbit 9y ago
    Protip: if no one's ahead of you, you're leading :-) This is a great answer. I think the impedance-mismatch question is a big part of the problem. Personally I prefer to boil the ocean rather than drowning in the impedance-mismatch tarpit. Both of these strategies are, of course, profoundly insane. It's true that a file-open dialog box easily becomes a powerbox. But of course, you are using the ambient authority of the user's login session to ascribe authority to the path that gets typed. So in a way it's the exception that proves the rule. And does a URL bar easily become a powerbox? What about a command-line shell? Perhaps we're both just agreeing that there is always trivial ambient authority, and the right way to scale up to nontrivial cases is a capability model. I just worry that when too many people discover the beautiful screwdriver that is capabilities, they decide that everything should be a screw. But the world has nails. It may even be true that the world should have nails. And then you find yourself pounding in nails with the butt of your screwdriver. Have you considered an ICO? Asking for a friend :-)
    - kentonv 9y ago
      I agree that capability people tend to get too extreme, and this tends to lead to failure. With Sandstorm we've tried to be more pragmatic, but still careful not to do anything that breaks the whole model in the long run. Whether or not the URL bar of a browser is a kind of powerbox depends on how extreme you want to get. In a pure capability model, yes, it would have to be. And hypertext would no longer be plain data -- it would be data with embedded capabilities (for each link), and would have to be transmitted via a protocol that can track capabilities. Obviously that kind of stuff, even though it would be amazingly powerful in a lot of ways, is not practical. :/ > Have you considered an ICO? Asking for a friend :-) People keep asking me that, often citing Urbit as an example to follow. :) At the moment I'm having too much fun at my day job building Cloudflare Workers (an unusually practical project by my standards!), and want to focus my outside-of-work time on coding Sandstorm rather than fundraising for it. In the future, who knows.
      - urbit 9y ago
        If I can distill my objection to the pure capability model: there are two different statements of the capability manifesto, one strong and one weak. The weak capability position is that it should be possible to construct an opaque combination of designator and authority, ie, a capability. The strong capability position is that designator and authority must always follow the same path. So in the "pure capability model," you are actually subtracting a feature from the system. Now, of course, it's often the case that subtracting a feature makes a system better. But one needs to be really clear about confusing this with the positive virtues of just having capabilities. Also, while I agree that capabilities are really great (Arvo has a somewhat capability-like internal communication model), it's important to point out that (a) capability vs. identity is a duality; and (b) it's cheating to compare a good capability system to a bad identity system. For (a), note that identity systems can implement capability features like delegation and revocation; they just have to do it actively rather than passively. If I am willing to act as your deputy, I can delegate my power to act to you. Or some restricted subset thereof. Tell me what to do and I'll do it. For (b), if you put a decent capability system next to the Internet, a network whose identity model is a burning-tire dumpster fire. If your identity system actually works and makes sense, competing is harder for the capability design. I do think Urbit should have some kind of capability model. However, this has the feel of a 2.0 or even 3.0 feature. I hate to solve a problem until it is actually in my way. I feel we have come nowhere near the limits of the common case. A simple map from identity to privilege is certainly that. And while capability UIs may be doable, identity UIs are trivial. This would not be the first case of humans being funky, hence screwing up our elegant architectural logic. If you have a system software project and it can advance without being lashed to a company, definitely do it that way! It's always a poor fit -- they have to succeed on different timelines. One thing I know: once we all have personal servers, today's cloud will look pretty lame in retrospect...
- EtDybNuvCu 9y ago
  Unforgeability can be weakened systematically to unguessability: https://capability.party/philosophy/2017/07/29/unforgeable-vs-unguessable.html https://capability.party/philosophy/2017/07/29/unforgeable-v... Unfortunately, the concept of "taming", where ambient-authority systems are used to implement functionality in capability-safe systems, is often a sad and frustrating path due to massive impedance mismatch. Like you say, paths are not caps, which means that capability-safe languages on UNIX-like systems are constantly dancing to tame the OS. As usual, it would be great if you made your VM cap-aware, so that we may eventually get over this hump.
  - abecedarius 9y ago
    It's worth noting that WebAssembly should go nicely with capability systems. Mark S. Miller started a thread on the mailing lists recently about making sure it stays that way.
kentonv 9y ago
My opinion, as the designer of Sandstorm, a capability-based server OS: Capabilities are not the way developers are used to thinking. It may be that if people got used to it, it would make sense -- or it may be that it's simply too complicated and most developers will never wrap their heads around it. I honestly don't really know which it is. In this respect, it feels a lot like functional programming (FP and capabilities are very different concepts, but are similar in that it takes a while to fully understand how to use them effectively). We do see capability systems appearing by accident all over the place. Unix file descriptors, for example, behave very much like capabilities. Once open() finishes successfully, all access checks are done -- they aren't repeated for every read() or write(). You now have a capability, and you can even send that capability to other processes (even running under different UIDs that wouldn't have permission to open the file directly) via Unix domain sockets. People who really get how to exchange file descriptors build some amazing systems with them (without ever realizing they're building capability systems). But, for some reason, most systems do not really try to take advantage of FD passing, and instead opt to do things like listen on a globally-accessible port and perform an authentication handshake on incoming connections. I guess this kind of design just seems more obvious to people? But often, as systems get more complex and involve more parties, they end up forced to use capability-ish designs, because ACL-based designs get intractable. OAuth's use of bearer tokens, for example, is very capability-ish, albeit not acknowledged as such, and a fairly primitive form of capabilities. This sort of design turns out to be necessary in large-scale systems. If people would learn capability theory before designing such systems, they'd probably be more secure and powerful.
- im_down_w_otp 9y ago
  Well... Kenton, now you've now got my brain stirring on whether or not the perceived complexity & opacity of ocap is an artifact of how tightly it has bound itself to the concepts of OOP (as something of a personal character flaw I find OOP to be fairly obfuscating beyond trivial domains for whatever reason), and whether or not FP concepts applied to a similar domain as ocap might provide me with clarity in security design/implementation the same way FP gave me clarity in program design/implementation eventually. None of which I really have excess time to noodle about, but is now unavoidable. Thank you, sir.
kmicklas 9y ago
IMO Unix is plenty bad enough to warrant replacement but unfortunately its iron grip on computing dooms any good ideas like capabilities in the short to medium term (at least 10 years).
gumby 9y ago
A big one is the cost of defense against forgery. A capability is essentially an index or pointer into a table in kernel space (much like an FD as another poster mentioned). The traditional mitigation is to use hardware tagging and permit the tag bits to be set only via a privileged instruction, e.g. Multics. The x86 segmented memory model also allowed this, and I used this to build some experimental SUID memory-mapped the 1990s (you could call into them via special gates, but not read the instruction memory, for example). Although you those memory models are still supported on x86 for back compatibility I don’t believe they are particularly fast any more, unfortunately. Edit: The lowrisc (RISC v) folks are implementing tagged memory also btw
- EtDybNuvCu 9y ago
  Capabilities are either unforgeable or unguessable, depending on your vantage point: https://capability.party/philosophy/2017/07/29/unforgeable-vs-unguessable.html https://capability.party/philosophy/2017/07/29/unforgeable-v...
- kentonv 9y ago
  Seems like you're talking about hardware capabilities, which haven't really been tried seriously since Intel's iAPX 432 processor in the early 80's. It failed miserably due to horrible performance, but some argue that the performance could have been fixed had they been given a second shot at it. Modern capability systems don't rely on hardware support and performance issues aren't usually cited as a problem with capabilities. In fact, capabilities can often perform better than ACLs since ACLs tend to require performing an expensive access check on every operation.
  - eb3c90 9y ago
    Thought it worth pointing out that Cheri are giving hardware capabilities another go. http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
  - gumby 9y ago
    yes, I was talking about hardware tagging, else you can’t protect capabilities solely in user space. Intel had tagged memory in the 90’s era i960 as well and, as I edited my comment to mention (thanks to your comment!) several others including most recently RISC-V). IMHO the 432 had other structural problems and it wasn’t the tagging that killed it but it had enough problems that this is definitely not worth disagreeing about — perhaps that was indeed the straw that broke that camel’s back.
eb3c90 9y ago
They have got some adoption. Android security model is somewhat capability security based. However it is used in an insufficiently fine grained way. It does highlight some ways that it may not work if used for desktop, programs would just ask for large-grained capabilities (can I access all your pictures/files etc) and you get back to ambient style authority. I think expecting the user to be an intelligent judge of what capabilities a program needs, is not realistic. I think something like agoric auction of capabilities might force programs to provide useful features to get access to data, might work. I'm exploring it anyway.
- abecedarius 9y ago
  Marc Stiegler suggested having a set of standard authority bundles for when you're installing more or less standard app types. (Of course this raises the question of getting to a standard designed with users' interests in mind.) Then an app wanting undue authority would have to incur the pain of getting users to install it in a special unusual way. (He made that suggestion back before Android etc. existed.) People are pretty OK at judging and tracking what to entrust other people with. This suggests the problem shouldn't be impossible, but that our interfaces don't map well to those familiar abilities.
  - jgtrosh 9y ago
    > Then an app wanting undue authority would have to incur the pain of getting users to install it in a special unusual way. Isn't that similar to getting people used to installing anything they find on the web on Windows and just pressing accept for everything? I'd say a viable system needs to explicitly address special authority and make users are of it as an important thing, but still within the normal course of UX, to keep the distinction meaningful. The current state of Android is in the other direction: it explicitly addresses authority for many accesses, but they're not fine grain enough; so apps ask for a lot, getting people used to accept early without having a clear idea of what the app will do in the future, making it cheap for the programmer to ask for many accesses.
    - thingification 9y ago
deepnotderp 9y ago
Most C and C++ programs won't work then due to the way programmers have built them.
bsder 9y ago
Performance, mostly. Operating systems have tweaked the performance of user->kernel transitions to the point that anything placed on that path represents massive degradation in performance. Until we start having to pay performance for security, no one is going to bother. Meltdown and Spectre are really the first security attacks that will require significant amounts of performance to mitigate. Once we get enough of those kinds of attacks, people will start being willing to trade performance for security.
- kentonv 9y ago
  No, performance is not usually cited as a reason against capabilities. Capability-based authorization usually has near-negligible cost to evaluate -- certainly less than the cost of evaluating ACLs. The problem with capabilities is that you have to design your code differently to use them effectively.

EGreg 9y ago

Capabilities have the following downside vs ACLs: Someone can share them with someone else. ACLs can be thought of as server-side mechanisms to increase the "specificity" of capabilities. The typical capability that ACLs work with is "identity", ie "I have access to this account." The idea is that people won't be able to delegate fine grained capabilities to someone else without giving the broad capability (access to their whole netflix account etc.) Now, the downside of ACLs is that they're much harder to do in a distributed computing fashion. So instead of blockchains etc. you have to trust a certain backend, and that backend can lock you out or become compromised. Think of capabilities as client-side controlled access tokens and ACLs as server side controlled ones.

kentonv 9y ago
> Someone can share them with someone else. Delegation is a feature, not a bug, because: > the downside of ACLs is that they're much harder to do in a distributed computing fashion. That's because large-scale work almost always requires delegation. So using a system that tries to prevent delegation is really shooting yourself in the foot -- but it seems fine at first, as long as the system stays simple. You only run into trouble when things get complex, and the ACLs become completely impossible to manage, but by then it's too late to make a fundamental design change. Now, you might insist that in some cases, you really do need to prevent delegation. But it turns out ACLs don't really enforce this: I can always set up a proxy server that has my credentials and provides some API to another user, hence delegating my authority with whatever granularity I wish. No ACL system prevents that, hence no ACL system prevents delegation! Usually, what you really want is not to prevent delegation entirely, but rather to prevent accidental policy breaches. That is, you trust that people aren't maliciously trying to circumvent the rules, but you aren't sure that your users fully understand what the rules are or why they are in place. This especially comes up in compliance scenarios: HIPAA or ITAR restrictions might legally prohibit delegating some data, but the rules are so complicated that not every employee in your company understands them. So, you want to enforce some basic policy rules that prevent them from doing so. It turns out this is a UI problem, not a security problem. In either an ACL system or a capability system, it's easy to design a UI that prevents such user error, without the need to fundamentally change the underlying security architecture. But, we're too used to thinking of these compliance problems as something the basic security architecture should enforce, rather than as a UI problem. So we keep shooting ourselves in the feet.

eadmund 9y ago

My own favourite metaphor for capabilities is that they are like physical keys. If I have a key, I can easily go to a shop and make a copy of that key, and give it to someone else. That other person will have all the access to the things behind the lock that I have.

kentonv 9y ago
Yes, but note more advanced capability systems go beyond that. You should not only be able to give a friend a copy of your key, but also be able to revoke their copy at any time, without also revoking your own copy or any other copies you gave out. You should also be able to set things up so that your friends' usage of the key is logged where you can see it. Your friend, OTOH, cannot see the logs of your use. But if your friend makes another copy to give to a third party, both you and your friend can see the logs of that third party's access. And if you revoke your friend's access, the third party is transitively revoked as well. That is to say, it's a tree.
- EtDybNuvCu 9y ago
  Indeed, a capability is like a smart key. But it's more flexible than that; capabilities can run arbitrary code, like a smart card. And since capabilities can manage references to other capabilities, really a capability is like a smart executable contract. This is precisely where "smart contract" comes from. I should probably write a blog post about this.
- AgentME 9y ago
  Also, depending on the system, you could mint a copy of your key that can only access part of your locker. If your friend is really good at fooing widgets, you don't want to do it yourself, and you don't want to continually bring all of your heavy widgets to them, then you can make a copy of your key that can only access the part of your locker holding your widgets and give that to them so they can come by and foo your widgets for you. With this system, you don't have to trust your friend to not mess with the other contents of your locker. You don't have to trust them to not take the money or personal documents you have in the other part of your locker. Maybe you believe you fully trust this friend, but maybe you don't fully trust their key-handling. If you gave them a restricted key, and you think one of your personal documents is missing from your locker one day, then you can skip worrying about whether it was your friend that's responsible. If your friend loses their key one day (they misplaced it, or someone stole it from them), then you don't need to freak out and worry about your personal documents; it's only your widgets that are in danger. If someone knows that your friend is given a lot of unrestricted keys to people's lockers, they might be incentivized to try to steal/blackmail/threaten the friend for their keys so they can get to people's important documents; if it's known that the friend always requests restricted keys from people to foo their widgets, then an attacker who doesn't care about widgets isn't incentivized to try to attack the friend.

snvzz 9y ago

For a very simple explanation, look at the Genode Foundations book (free, available on their website)

loeg 9y ago

One interesting application of the idea of capabilities to an existing POSIX system is FreeBSD's Capsicum. (There is also a Linux port of Capsicum, but it has not been integrated into Torvalds' tree.) In Capsicum, capabilities are tracked on a per file descriptor basis. A typical program opens any input paths, restricts capabilities on open fds (including stdio), and then enters sandbox mode. Once the capability mode sandbox is entered, no additional capabilities can be granted, and filesystem access via absolute paths is revoked. (Sandbox mode programs are expected to access files they already have open, or to use relative accesses to walk file trees.) Erroneous system calls generate ECAPMODE or ENOTCAPABLE errors if they attempt to perform actions they do not have permission to do.

Majora320 9y ago
What prevents a Sandbox mode program from just using a chain of `··`s to access the root?
- ithkuil 9y ago
  IIRC openat(2) honours the sandboxing rules
- loeg 9y ago
  Access to ".." above the "root" of a given dirfd are disallowed in the sandbox. So for example, if you have an open dirfd with the LOOKUP capability when you enter the sandbox, you can access the following relative paths: ".", "./foo/bar", "./foo/.." But you cannot access these relative paths: "..", "./foo/../..", etc.

CMCDragonkai 9y ago

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).

hierophantos 9y ago

I have also made bulleted notes of this article a few months back: https://github.com/hierophantos/capable https://github.com/hierophantos/capable Talking to one of the "O-Cap Gang", Norm Hardy (http://www.cap-lore.com/CapTheory/ http://www.cap-lore.com/CapTheory/) a few weeks ago, he said, to the point of creating secure distributed computing architectures: "Object capabilities are not easy, but they're the only way I see forward." I'm biased to agree.