[cap-talk] Capability Semantics (was: Re: Third ABAC TechTalk)

[Jed at Webstart]

At 11:36 AM 7/25/2006, Tyler Close wrote:
>On 7/24/06, Jed at Webstart <donnelley1 at webstart.com> wrote:
> > At 03:57 PM 7/24/2006, Tyler Close wrote:
> > >I am arguing that if we wish to make use of our existing WWW software,
> > >such as browsers, we need to use a capability representation that is
> > >supported by this software. AFAICT, a password capability is the only
> > >capability representation that is backwards compatible with our
> > >existing software.
> >
> > I assume you also include software such as email clients and
> > servers, perhaps protocols like LDAP, PAM, im, etc., etc.
>
>Yes, I am interested in applying capability concepts to other
>protocols, but I also think HTTP is currently the most important
>protocol and will continue to be so for the foreseeable future. I have
>therefore been putting most of my effort into developping tools that
>work within HTTP.

I can understand an emphasis on http, but I think at least email
must be included.  At present it seems that email is nearly (absolutely?)
the only means for individual domain to domain (e.g. person to
person) communication.  Without the ability to safely send
capabilities in email, it's difficult for me to see how any richer
object based sharing structure can be built up.

I'm specifically concerned about the data theft problem for
email.  If capabilities in email are essentially passwords, I
believe all sorts of nastiness will result and capabilities will
(unfortunately and inappropriately) get a bad name as a result
(e.g. all the complaints even now about the weakness of
'capabilities as data' that people incorrectly identify with
password capabilities).

I believe it's vital for capabilities to be able to be sent safely
in email.  Assuming secure email is fine, but I don't believe that
alone adequately solves the problem (looking over shoulder,
archives, etc., etc.).

I do think communication of something like PGP/GPG encrypted
blocks of data would solve the data theft problem effectively.
In fact if such blocks were signed it would even solve the
"Reflection Problem":

http://www.webstart.com/jed/papers/Managing-Domains/#s11

(an instance of a confused deputy), but at the cost of some
very inconvenient manual manipulation by users.  What I'd
like to see is something along those lines automated and
integrated into email text (e.g. along the lines of the way
images are so integrated) so capabilities can be safely and
conveniently copied and pasted into and from email messages.

> >  In each case I believe a suitable adaptation is needed.
>
>I put some effort into specifying the web-calculus protocol at an
>abstract level <http://www.waterken.com/dev/Web/AMP/> and a concrete
>syntax level <http://www.waterken.com/dev/Web/HTTP/>, to facilitate
>such adaptation.

I reread through the above and neither seem to me to provide the
needed protection so that capabilities can be stored and manipulated,
even displayed, in such a way that they can't be stolen, while at
the same time providing a mechanism to allow a domain (and only
the domain) to translate them for access.  I'll get off this horse as it
doesn't seem to be going anywhere, but I think you know what I'm
talking about - essentially the facility of:

http://www.webstart.com/jed/papers/Managing-Domains/#s13

if not the mechanism.  I believe many people are sincerely and
rightly concerned about data theft for password capabilities.

Regarding:

>...in local computation, confinement is implementable.
>Confinement in not implementable in distributed computation.

and later:

>A network protocol cannot (on its own) implement confinement

I think we agree that confinement (aside from wall banging, where
the local case is actually more difficult) requires a mechanism
that limits active objects (processes) to communicate only to
specifically permitted addresses.  For example, only allowing
communication to other active objects that they have a capability
to.  I think we also agree that various means can be used to
achieve such limits, e.g. Plash/Polaris sorts of mechanisms
(perhaps needing network augmentation?), some descriptor sort of
capability mechanism (e.g. DVH) or even a capabilities as data
mechanism (e.g  Amoeba or NLTSS) where processes are only
allowed to communicate through capabilities.

Regardless of any means of achieving confinement (or not), I
argue that it's important to have a mechanism for communicating
permissions that operates from the local (e.g. language) through
the network level.  There is nothing inherent in capability semantics
that requires differences across those levels.  A remote capability
can be communicated and invoked just as effectively at the
language level as can a language capability can be communicated
and invoked at the network level.

So, when you ask:

>Do you have a short summary of your model?

Sure.  It's simple object capability semantics at all levels.
That is, we need a mechanism for invoking capabilities
and sending in data and capabilities and (in general) getting
capabilities and data back.

I think the main difficulty is at the next level down.  Namely,
how do we implement such a facility across levels and locations?
To me this is mostly an issue of marshalling and un marshalling
parameters.  I see capabilities as entities that have (or should
have) the same semantics at different levels and locations
and like other entities (e.g. floating point numbers, integers,
strings, etc.) may change representations as they move
from place to place.

A password capability is convenient in that it's a block of bits
that can be used without change.  This makes it convenient
for moving through mechanisms that can only deal with unchanging
blocks of bits.  To me it doesn't seem to be asking too much
to develop APIs and GUIs that can deal with capabilities whose
representation can change.  I'll give two examples of representations
to give you an idea of what I have in mind:

1.  Capabilities that require translation (e.g. translation into and
out of buffers for protection from data theft as in:
http://www.webstart.com/jed/papers/Managing-Domains/#s13
).

2.  Descriptor type capabilities.  In this case the representation
will point to something like a c-list index.  When the communication
happens the data will be modified to point to where (again a c-list
index) the capability arrives at the destination.

Along these lines, but of lesser importance (How am I doing MarkM?)
I'll note (perhaps to loosen up some thinking), regarding:

>We know it's not possible. ... a network protocol requires the
>existence of secret bits.

It doesn't (don't believe everything you know?).  It may be most
conveniently, practically, or efficiently implemented with secrets,
but it can be done without them. Both the DCCS architecture:

http://www.webstart.com/jed/papers/DCCS/

and the ACL based mechanism described in:

http://www.webstart.com/jed/papers/Managing-Domains/#s10
and http://www.webstart.com/jed/papers/Managing-Domains/#s11
(similar but with a confused deputy problem corrected)

implement network capabilities without any secrets.  They do depend
on correct communication of network addresses (which one could
argue in some cases need to depend on secrets), but such addresses
can be assured with hardware means in some cases (e.g. in a
LAN or cluster) - very much along the lines of the way descriptor based
capability mechanisms work within a shared address space where
addresses are assumed to be correct.  Communicating across a
network (e.g. LAN or WAN) vs. communicating within an SMP
has no direct impact on capability semantics, only on implementation
"detail"s.

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