[cap-talk] Selling capabilities programming

[Jed Donnelley]

At 03:04 PM 7/15/2007, Jonathan S. Shapiro wrote:
>On Mon, 2007-07-16 at 06:44 +1000, James A. Donald wrote:
>...
> > In the context that we are defending the users from
> > malware, rather than management from users, restricting
> > the propagation of permissions strikes me as useless.
>
>Actually, it is *exactly* this context in which it is useful, because
>restricting permission propagation is the essence of the power box
>design that you advocate. The power box approach is founded on authority
>confinement, and cryptographic capabilities cannot be confined.

Hmmm.  I'm a bit puzzled by the above, so others might be also.

 From what I understand, the code in a power box is assumed to
have access to all a user's authority.  As such, if a program
asks for additional access (e.g. to open a file for reading
and/or writing) the power box program can safely present this
option to the user, allowing the user to name or otherwise
specify a file or other permission that the user authorizes
the power box to communicate to some running program that is
otherwise constrained by POLA.

If the above is a correct view, then it seems to me that
any confinement property of capabilities (e.g. in the
purest form the bundling of the permission to communicate
with the designation and permission for some access to
an object) is less important for the power box code than
it is for, say, the running applications that the power
box is doling out permissions to on the user's behalf.

I expect at least this would be the view of the MAC
community (still looking for a name or other means to
refer to this generally defense/military/government
oriented community).

It is certainly true that a running power box would be
expected to have a lot of permissions that it might
inappropriately 'leak', but by that same token (non
premeditated pun) it would be likely to have all
a users permissions to communicate (e.g. open access
to the Internet) and would be unlikely to be effectively
confined, even if its capabilities provided it's only
means of communication.

With the above expansion, if I return to Jonathan's statement:

>restricting permission propagation is the essence of the power box

that statement does indeed seem to me to fit with my
thoughts above, however it does so in the sense that
the power box is programmed to only communicate selected
permissions by human user direction across a presumed
widely available ability to communicate.

So then this statement:

>The power box approach is founded on authority
>confinement, and cryptographic capabilities cannot be confined.

doesn't seem to fit to me.  To me the power box
mechanism seems to fit perfectly well with cryptographic
capabilities.  Perhaps it would be helpful to separate
what I see as two rather distinct dangers that the
power box might be seen to defend against:

1.  The danger that a running program might get
more than POLA access to a user's authority.

I believe a power box can provide such value with
cryptographic capabilities.

Another possible danger is:

2.  The danger that running programs might leak
(inappropriately give away to others) permissions
that were appropriately given to them, e.g. in accord
with POLA by initialization or by a power box.

In this second case if a programming environment
is using cryptographic capabilities and the
running programs are assumed to have an
unconstrained ability to communicate (e.g.
with the Internet), then of course as we know
the running program can conspire to make any
permission that it is given available to others
on the network (conspiring communicators),
so the value of the power box seems limited
to case #1.

Still, I believe case #1 provides value.  For
example, consider case #1 in the context of
YURLs or Widewords.  I could imagine a situation
where I'm interacting with some remote service,
and that service needs access to, say, some
file (perhaps a tax return of mine?) to provide
the service I want.  If it provided an upload
window, isn't that window providing essentially
the service of a power box?  Perhaps it would
be a bit more direct if instead of uploading
the contexts of the file I just provided it
with a YURL/wideword that grants it access to
the file (e.g. for reading).

At that point I accept that the service at
the other end can grant any such permission
to others.  Perhaps we would hope for better
confinement of the remote service (though as
a service provided on the Internet I'm not
sure how I would come to trust any such
putative confinement of such a service), but
I can at least only give it access to the
permissions that I need it to have to perform
whatever service I want (e.g. access to my
tax return in the above example).

Perhaps Jonathan or others can tell me what I
might be missing in the above.

--Jed  http://www.webstart.com/jed-signature.html