Re: "Ambient capabilities"

On Mon, Nov 3, 2014 at 5:37 PM, Tony Arcieri <[email protected]> wrote:

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

You certainly aren't getting the benefits of precisely indicating which
authorities you're using for each action. A user is subject to the confused
deputy problem.


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

Assuming that it's easy to control, attenuate, and reason about the
environment exposed to different subprograms, then the idea of having
capabilities floating around in the environment doesn't hinder POLA. But,
from your description, I'm guessing this is not the case.



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

Passing a cookie full of capabilities to a URL shouldn't be much different
from passing a context object to a function or object; i.e. you can think
about it as a delegation of your authority to whatever agent is named by
the URL.

But even if we grant a bag of capabilities, the agent/server/script at the
endpoint should be explicitly drawing an appropriate cap out of the bag (or
their own personal inventory) for each action. This would restore many of
the benefits of capability security on the server side. It seems to me
you're instead saying that the bag of capabilities is treated more like
advice, with the scripts themselves having ambient authority.


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

I feel the phrase "ambient capability" would better describe scenarios
where capabilities are published to public or shared arenas, and users or
agents with access to these arenas are thus free to grab the capabilities
they need to perform some action. The capabilities are essentially
'ambient' as far as the agents and users are concerned, but they're also
clearly recognizable as capabilities, coupling authority and designation.

Relevantly, in that scenario, nobody is "deciding whether an action is
permitted" based on the bag of caps available to them. Rather, the bag of
caps determines which actions are available to the agent.


> what's a better phrase to describe them? "Ambient permissions"?
>

"questionable hack"?

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