Macaroons as capabilities (Was: Second hand sharing)

The idea of Macaroons as pure capabilities is intriguing to me. Sorry to
throw everyone into the middle of a conversation on it, but I think we're
teasing out some of the essential concepts.

CCing a few other lists who have opinions on this stuff as well.

On Mon, Feb 2, 2015 at 11:07 AM, Robert Escriva <robert-oHZo/[email protected]> wrote:

> The exact scenario I wish to avoid is the following:
>
> 1)  Client makes a request with a macaroon for "/photos/private.jpg"
> 2)  The application pulls "/photos/private.jpg" from the macaroon to
>     decide on the resource being requested.
> 3)  The application builds a verifier that says that the resource being
>     accessed is "/photos/private.jpg".
>
> We've found ourselves in a situation, where the verifier is proving a
> tautology.  It is trivially true that the macaroon matches the
> information we pulled from the macaroon, which means we will always
> authorize the request.
>

What you're describing sounds like a pure capability. I'd go further and
say a pure capability:

- Should pertain to a single "object" (or "actor")
- Authorize one specific action
- Be necessary and sufficient to carry out that action


> The difference here is subtle.  In the first scenario, the macaroons are
> first looked at in step 2, but the verifier is built in step 3.  In the
> second scenario, the verifier is built in step 2 and the macaroons are
> handled in step 3.
>
> The principle at play here is that the verifier should always be built
> using only the information available in the request/environment without
> consulting the macaroons.


This doesn't sound like capabilities, this sounds like the antithesis of
capabilities: ambient authority.


> This ensures that applications are always
> checking that the macaroons are a proof that the request is authorized,
> instead of inadvertently checking the macaroons against themselves.
>

I suppose the difference with capabilities is subtle too: they must
authorize one specific action against one specific resource (i.e. object,
or "actor"). If you haven't read it before, I suggest checking out Ben
Laurie's paper "Access Control":

http://www.links.org/files/capabilities.pdf

Achieving this property with Macaroons is difficult, but possible IMO.

One place where a "pure capability" usage of Macaroons might differ from
other uses is rejecting otherwise valid Macaroons. A Macaroon might be
rejected if it does not express sufficient constraints as outlined above.
This isn't an authorization error, but a usage error. And ideally such
errors shouldn't happen, because we have a framework that respects objcap
principles minting the Macaroons in the first place.


> Macaroons actually embrace the capabilities school of thought.  The
> initial secret used to construct the macaroon should be associated with
> the resource being accessed.  In a key-value store like HyperDex, it's
> stored alongside the key.  In a disk-like device, it might be stored in
> the same block as the data.  In a photo service, there's one secret per
> photo.  This eliminates the potential for a confused deputy, because the
> verifier will only report "authorized" when provided with the secret
> associated with the resource, and only when the macaroons themselves are
> a proper, well-formed, proof.


What you're describing does indeed sound like a capability system: each key
in a k/v store should have a *set* of Macaroons, which authorize specific
types of actions (one macaroon per action)

If we can solve pure capabilities in terms of Macaroons, we can do some
things that are traditionally a bit "hard" in capability systems, like
confinement and revocation. Capability systems ordinarily solve these
problems in terms of proxies, but with Macaroons they can be expressed
offline in terms of caveats.

-- 
Tony Arcieri

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk