"Ambient capabilities"

In the past I have worked on crypto-capability systems
<https://github.com/livingsocial/keyspace> which, I think, faithfully
implement capabilities in the traditional sense: each capability takes the
form of a token which combines a cryptographically secure resource
identifier with a cryptographically secure authority (i.e. one or more
cryptographic keys), the result of which confers a specific authority for a
specific resource, e.g. "read from file X" or "write to file X", all of
which is encapsulated into a single crypto-capability token which is
necessary and sufficient to access a resource. This is much like
capabilities as implemented by Tahoe-LAFS or Waterken.

Lately I have been working on a combination access control and single
sign-on system where I have been pushing for something close to
capability-style AuthN/AuthZ: each application exposes a fine-grained set
of permissions, each permission confers a highly specific power,
permissions are always explicit and never inferred, and the entire system
strives to follow the principle of least authority.

As I reflect on it however, I find it's not really capabilities in the
traditional sense at all, but falls into a category better described as
"ambient capabilities", a concept which seems to have been heavily
discussed (in a largely negative context) when Netscape originally tried to
implement something similar:

http://www.cap-lore.com/CapTheory/AmbCaps.html

See also:

http://zesty.ca/zest/out/msg00139.html

There are a few reasons why the system I've developed fails to live up to
the true ideas of capabilities:

Each user has an application-specific bearer token. While authority is
constrained on an app-by-app basis, the cookie passes through all of the
capabilities a user possesses for a given application with each request,
and if any of them confer the necessary authority, the action is permitted.

I feel like this is bordering on ambient authority: these "capabilities"
sort of float around in the environment of an operation, and something
making an access control decision inspects what's in the environment to
decide if an action is permitted. I think in a "real" capability system the
*client* of the service would select the *specific* capability needed to
perform a particular operation on the server and send that and that alone
as part of a request. That is not how my system works today.

Finally, the name of the target URL endpoint and the "ambient capability"
are not entwined in any way, rather, right now it's up to the target
resource to decide which actions should be permitted. This seems like the
coup de grâce for my system actually being capability-based: the name of
the *specific* resource and the action to be performed are not entangled.

Modeling this as an objcap system, we might think of one of these "ambient
capability" tokens as being entangled with a particular object, but access
control decisions made on a method-by-method basis must still inspect a bag
of "ambient capabilities" to decide whether an action is permitted. From a
coarse grained perspective (i.e. the object level) we have something
approaching a capability, but from a fine-grained perspective we do not. I
have always thought of capabilities as being more like the authority to
call a particular *method* on an object (i.e. we have a file object with
read and write methods, and each should be modeled as a separate
capability) as opposed to some sort of blanket access to an object as a
whole.

So, perhaps, these aren't capabilities at all. They end up looking quite
like X-Sandstorm-Permissions header used by Sandstorm:
https://blog.sandstorm.io/news/2014-08-01-mediagoblin.html

So what do people think? If these aren't to be considered capabilities,
what's a better phrase to describe them? "Ambient permissions"?

If the consensus is that this approach does not truly implement
capabilities, I'd either like to move to a *real* capability system (I have
been looking at Macaroons a lot which at least feels to me like a
capability system), or remove any sort of "capability" branding and rebrand
with a different word to avoid overloading the term "capability".

-- 
Tony Arcieri

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