Re: "Ambient capabilities"

On Mon, Nov 3, 2014 at 6:26 PM, David Barbour <[email protected]> wrote:

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

Indeed the capability to grab out of the bag for each URL endpoint is
specified in a nicely declarative way, i.e. every endpoint is called out
specifically, and the necessary (cryptographically authenticated)
"capability" name to access it are declared right next to the URL in a sort
of 2-tuple. No access is allowed unless one of these 2-tuples has been
declared and the client has the correct capability.

However this decision is made by the server, not the client. The client
always presents the "bag", and the server looks in the bag to see if the
requisite "capability" is indeed in there.


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

That's true, however the client may be providing more authority than needed
for most actions.


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

LOL. I think it works well for Sandstorm given the legacy constraints.

-- 
Tony Arcieri

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