Capability Based Security

https://en.wikipedia.org/wiki/Capability-based_security

by jacquesm • 11 years ago

44 35 11 years ago

en.wikipedia.org

laarc• 11 years ago

Hey, Jacques. I wanted to say that I'm happy you're still around HN. Thanks for sharing a lot of interesting stuff, and experiences regarding business and life in general.

I was just thinking how emptier HN would have felt without all that over the years, so...

Best of luck! Happy holidays.

jacques_chester2• 11 years ago

Thanks! That's very gratif-

jacques_chester2• 11 years ago

As it was explained to me, the main problem with capabilities is working out how to revoke them.

You either have expiring capabilities, which is a hassle but probably inevitable. Or you have revoked capability lists, imposing an additional cost on every single invocation. The latter was a bit of a killer once people had figured out clever, fast bit-operation ways to check a capability, because the cost of looking up the list swamped the gains from bit-twiddling optimisations.

Mind you, we sorta wound up with it anyhow, in the form of OAuth tokens. And here the algo-economics changes again to favour it: the cost of a network roundtrip is gigantic compared to any comparison operation, so it doesn't seem quite so bad after all.

willvarfar• 11 years ago

It's hard to generalise like that. There are lots of flavors of cap system.

On many hardware capability-based addressing systems it is easy to zap them by clearing the corresponding bit in the capability mask. However, the problem then becomes how to revoke a cap from some holders and not others etc (which can be done with chains and ... turns into an interesting permission-like system ;) ...)

Permission-list systems have exactly the same problem too. IIRC munmap ends up walking linked lists on Linux rather like ancient heaps. It might have changed.

evancordell• 11 years ago

There's a paper called "Capability Myths Demolished" that addresses this. There's an online version here[0], see "revoking access".

Personally I'm fascinated by ocap systems and am always looking for ways to employ them. There are some interesting "modern" applications (aside from a couple of research kernels) like CapnProto and Pony language. Macaroons come close but are more of a hybrid approach to authorization. (They don't out of the box prevent confused deputy or anything)

[0] http://www.erights.org/elib/capability/duals/myths.html

bascule2• 11 years ago

Yes, Capability Myths Demolished describes the "revocable forwarder" pattern, which uses a proxy to delegate access in a revokable manner.

Macaroons on the other hand are nice because they don't need a proxy to solve this problem: the authorizer can issue a short-lived "discharge Macaroon" to authorize access, then the client can get to the target resource directly without the need to use a proxy. To revoke access: just refuse to issue subsequent discharge Macaroons when the current discharge expires.

abecedarius2• 11 years ago

To revoke them, the usual pattern is to never hand out the original capability, you hand out a wrapper that you can disable. E.g. in Javascript:

    let [revoke, revocable] = makeRevocable(cap);
    share(revocable); // share can call revocable(), which forwards to cap() unless revoked
    setTimeout(1000, revoke); // for auto-expiring, just for example

See section 4.3 in http://www.erights.org/talks/asian03/index.html

A capability system can help you batch up those round trips you mention, btw: https://capnproto.org/rpc.html

ChuckMcM• 11 years ago

This is exactly right. Back before Java 1.0 was released I was working on a capability based security model for it. The class loader would hand out what was essentially a virtual method of the instantiated class based on the capability's allowed. Revoking capability consisted of updating the template which would fail to resolve the revoked methods on the next call but leave the ones which were still on the stack.

nickpsecurity• 11 years ago

Applied to whole systems to make them more secure from hardware up:

http://homes.cs.washington.edu/~levy/capabook/

Modern project already running FreeBSD with capability security:

http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

Also look up CapDesk and DARPAbrowser.

kentonv9• 11 years ago

The brilliant thing about capability-based security is that it turns classic object-oriented programming patterns into security patterns.

Access control is implemented by encapsulating private members behind a restricted public interface.

Polymorphism allows you to add wrappers around an object implementing arbitrary security policies. E.g. want to revoke access to this object after some time? Add a wrapper where the methods forward to the real object until revoked, and then throw exceptions instead.

What's interesting is that these are patterns we are doing anyway, in real code, not for the purpose of security but for the purpose of correctness and maintainability. Because we were doing these things anyway, our programming languages provide really good tools for making them work naturally, and we already know how to think about them.

On the other hand, the competing model -- access control lists (ACLs), and other types of externally-specified policy -- are not things we were doing anyway. They're external concepts bolted into the system awkwardly. Because of this, they tend to be painful to maintain, which in turn means people often don't bother.

One of the clearest examples of how ACLs go against the grain: An ACL is a list of entities who are allowed to access a resource. These are effectively pointers pointing in the opposite direction of all other pointers in the system: ACLs point from the callee to the caller. This creates all kinds of problem. Just try to imagine how, in a programming language, you would specify the allowed callers of your object.

This translates to UX, too: Say you are using Google Docs, and you want to "share" access to a document with Alice. Traditionally this is seen (by the implementers -- I was once on the Google Docs sharing team) as a two-step process:

1. Grant access: Add Alice to the access control list.

2. Notify: Send Alice an e-mail notifying her that she should open the document.

Part 2 is obviously necessary and natural. You intuitively know you must tell Alice about your document.

Part 1 may sound obvious to any techie, but it's not at all: Users regularly forget this step, and we build all kinds of UI to try to recover from this. And even if it were obvious, it's problematic. What if Alice doesn't have a Google account? What if she does, but I don't know the email address tied to that account, because it's not her usual address?

What we really want to do is eliminate part 1 and have only part 2: Abstractly, when you notify Alice of the document, that notification should itself contain the permission to access the document. Then I don't need to know Alice's Google account ID, I just need to know how to send her a message containing the permissions. (This is analogous to sending a pointer in code -- receiving the pointer grants the recipient the ability to access the pointed-to object.)

This is the essence of capability-based security at the UX level: Deriving access control from actions you were already doing. The user rarely needs to be confronted with a security action, yet the right people end up getting access.

Some will argue that such implicit security is inherently dangerous because it's hard to audit and control. I argue that "explicit" security is dangerous because it's hard for users to understand and use correctly -- inevitably, many will simply turn the security off.

But there's a compromise: If the underlying system deeply understands capabilities and knows when they are being passed, it can maintain an "access control list" on the side, automatically populating it based on the observed movement of capabilities. This pseudo-ACL can allow the user to audit who has access to their document and revoke people who shouldn't be there. It also offers a place to hook in policies: if the system observes a capability movement that is contrary to some explicit policy (say, "documents shall not be shared outside the organization"), then it can revoke that capability.

This is the model we're implementing in Sandstorm:

https://sandstorm.io

https://docs.sandstorm.io/en/latest/developing/security-prac...

And Cap'n Proto RPC implement capabilities at the network level:

https://capnproto.org/rpc.html

(I am the lead developer of both Sandstorm and Cap'n Proto.)

Capability Based Security

Related Stories