[cap-talk] "ambient authority" on wiki.erights.org

Mark Miller erights at gmail.com
Tue Jun 23 21:59:45 EDT 2009


On Tue, Jun 23, 2009 at 6:13 PM, David Wagner <daw at cs.berkeley.edu> wrote:

> Karp, Alan H wrote:
> >I have been treating a static, immutable, authority carrying variable as
> >part of every object's creation state, not different in any essential
> >way from an argument passed to its constructor.
>
> It seems different to me, in some essential ways:
>
>  * With a global authority-carrying variable, you can't prevent some
>   objects from receiving this authority.  If it is passed as an
>   explicit argument to the constructor, you can.
>
>  * With a global variable, the default is to make this authority
>   available to all code.  If it is passed as an explicit constructor
>   arg, then the default is to not provide this authority.
>
> These differences seem important.  I realize this doesn't necessarily
> imply that a global authority-carrying variable must count as ambient
> authority, but at the same time I don't buy the argument that it is the
> same as a constructor arg and hence isn't ambient authority.
>
> Maybe it's worth going back to the justification for introducing the
> concept of ambient authority.  Ambient authority is dangerous because (a)
> it tends to lead to excess authority and violations of POLA, (b) it can
> lead to confused deputy vulnerabilities.  I think an authority-carrying
> global variable does tend to lead to excess authority and POLA violations;
> but it doesn't seem to lead to confused deputy vulnerabilities.  Does
> that sound right?  Did I miss something?



I think you, Alan, and (IIUC) Matej have it right: such variables provide
"undeniable authority". Systems with such sources of undeniable authority
violate the "loader isolation" criterion explained in my essential but
poorly written Ch10, and so are not ocap systems. The undeniable authority
mistake, the ambient authority mistake, and the excess authority mistake are
clearly coupled. And there may be example mistakes in a gray area between
them. Nevertheless, I think it is important to distinguish these.


-- 
Text by me above is hereby placed in the public domain

   Cheers,
   --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20090623/ebbf1abb/attachment.html 


More information about the cap-talk mailing list