[cap-talk] "ambient authority" on wiki.erights.org
sam at samason.me.uk
Mon Jun 22 19:03:25 EDT 2009
On Fri, Jun 19, 2009 at 06:29:21PM +0100, David-Sarah Hopwood wrote:
> Sam Mason wrote:
> > My understanding of ambient authority seem to be predicated on the
> > following:
> > 1) a minimum of three subjects; Ana, Bob and Charlie in this example
> > 2) Ana has a designator D that references an object known to Charlie.
> > D does not carry authorizing information
I'm not sure if I was using "designator" correctly here, by designator
I'm meaning any possible way of identifying an object known to Charlie;
all the way from human memorable names through password caps to
protected caps. Just some way of referring to some object. Rob has
used a much stronger definition recently and I'm not sure if there is
> > 3) Ana shares D with Bob
> > 4) Bob asks Charlie to perform some work on the object designated by D
> Ana is not essential:
The only way I can make ambient authority at all rigorous is to have
three subjects; the reason being that if there are *always* two or less
subjects then there isn't a problem as we know who is talking to who.
As soon as there is the option of three (or more) subjects in a system
(most interesting systems have an arbitrary number of subjects) then
it doesn't matter if Ana is explicitly named, it's enough to know that
another subject *may* have shared said designator with Bob.
The interesting case where we have just two subjects is that of writing
a simple utility program where I would say we have two subjects---that
of the running program and everything else outside. This utility can be
written as badly as it wants to be but I'd say it (on its own) can never
exercise the wrong authority.
A (single) user's shell is one where (I'd say) we have to worry about
multiple subjects. I'd say one subject is the shell itself, another
is created for every program the shell is instructed to run (i.e. at
least one in the general case), and another subject everything else.
Most interesting programs degenerate to this case as well because we
generally want to program defensively and don't want one part of our
program taking out unexpected bits and so I'd say we want to partition
things up and the term I've been using for these divisions is that of a
subject. While writing this I've realized that "subject" probably isn't
the best choice of a term, but I'm not sure what works better.
> 1) a minimum of two subjects; Bob and Charlie in this example.
If there are only *ever* a maximum of two subjects then I don't see how
there is ever ambiguity, as soon as there is the possibility of more
than two then we have the potential for ambiguity.
> 2) Bob has a designator D that references an object known to Charlie.
> D does not carry authorizing information.
> 3) Bob asks Charlie to perform some work on the object designated by D.
> The system applies Charlie's permissions to these operations.
> That is, it doesn't matter where Bob got D; Bob could just as well
> have made it up, or got it from Charlie.
I'd not thought of the case of "making it up", but that's a good
To receive it from Charlie, Charlie must be written for the general case
of an arbitrary number of subjects. I would therefore say that the
ambient authority lies with Charlie; Ana exists, but just isn't named
explicitly and takes the role of the other arbitrary users that Charlie
is being written/modeled for.
> In the typical case
> of a confused deputy attack, D comes from an attacker, but an
> attacker is not necessary for the definition of ambient authority.
> It is also not necessary, in order for Charlie to be an accidentally
> confused deputy.
Yes, I think I agree with that.
For the chance of a confused deputy though we have to be in a system
that has been designed for the general case of an arbitrary number of
I've just realized that all this is just another restatement of what's
so nice about the o-cap model; it makes the case of two subjects into
the common case. The two subjects being "inside" the object and
More information about the cap-talk