[cap-talk] Argument for capabilities as data in NLTSS

[Jed Donnelley]

Jonathan S. Shapiro wrote:
> On Mon, 2007-07-16 at 11:28 -0700, Jed Donnelley wrote:
>   
>> I just thought I'd briefly repeat the argument that was made
>> during the early days of the NLTSS design that resulting in
>> favoring capabilities as data in that system vs. capabilities
>> as protected descriptors (classical capabilities).
>>
>>     
>
> The argument contains a flaw:
>
>   
>> 2.  If we were going to implement a serialization
>> protocol for network capabilities, then any computers
>> that had access to the network would have access to
>> what amounts to capabilities as data for any capabilities
>> that are distributed on the network.
>>     
>
> This seems to ignore the possibility of network layer encryption and of
> mutually authenticatable nodes. Automatically bootstrapping the latter
> has only recently become possible, but it clearly could have been done
> by hand at the time of NLTSS. Cryptography, of course, was then well
> established.
>
>   
I think perhaps the issue is more a lack of clarity in my description of
the argument.  When I say "any computers that had access to the
network would have access to what amounts to capabilities as data
for any capabilities that are distributed on the network." I didn't
intend to imply that computers which could "snoop" the network
traffic would get access to the permissions provided by the
serialized capabilities, but rather that when any computers on
the network properly received such serialized capabilities
(e.g. across encrypted communication facilities), they would
then be dealing with what amounts to capabilities as data.

Does that answer this?:

> So this assumption seems transparently wrong. What am I missing here?
>   

>> 3.  Why limit processes that run under some OS on
>> a network to having less access than computers that
>> run on the network?  By providing less access you
>> are really fooling yourself if you think that you are better
>> protecting your capabilities, because those capabilities
>> will still show up as data in the computers on the
>> network.
>>     
>
> It is fairly clear that we can protect supervisor memory from incursion
> by applications, so there is a clear distinction to be made between raw
> capabilities appearing in supervisor memory vs. raw capabilities being
> accessible to user-mode code.
>
> So this assumption also seems transparently wrong. What am I missing
> here?
>
>   
What I am arguing here is that once you launch a capability out onto the 
network, even
if you use end-to-end encryption of the channel, you have effectively no 
control over
the computer that receives such a capability.  It may be a capabilities 
as descriptors
system where the capability is essentially emulated for remote execution 
(e.g. along
the lines of DCCS or MarkM's vat system) or it may just deal with 
whatever serialized
form of the capability it receives and try to make use of it.  From the 
viewpoint of
the domain sending the capability the relevant receiving domain of trust 
at the other
end is the whole computer system, not just what might be imagined as a 
single
confined domain.  This is another case where I think the technique of 
imagining
communication to an extra terrestrial "intelligence" identified only by 
a public/private
key pair may be helpful.

Consider a system on a network communicating with MarkM's vat 
implementation.
Such a remote system may choose not to run E or anything like it and may 
just
try to make use of the permissions granted by knowing the serialization 
protocol.
That is a choice that's available to any such computer on the network.  
It may
spray any data that it receives and may proxy any permissions that it 
receives
anywhere on the network (available to it through firewalls and such of 
course).
It is only constrained by it's reputation and the network connection it 
has.  This
is all I was trying to suggest the argument was that was made for 
capabilities
as data for NLTSS.  The argument was that there seemed to be little value
in permitting processes (domains) in a single system to have less authority
to act as a full partner in the serialized capability communication protocol
that computers on the network have.

The argument that I believe was still valid but that I failed to adequately
defend was that there is added value in providing more limited ability to
communicate in local processes (domains) - namely "confinement"
that limits communication of such processes to POLA as per the
capabilities that they receive/have.  Specifically that by so doing we
can have better control at limiting the opportunities for programs
that may be less than trustworthy from sharing any data and/or
permissions that they receive from other destinations on the network.
> Jed: can you shed some light here?
>
>   
I hope the above does.  Thanks for taking time to consider the argument.

--Jed  http://www.webstart.com/jed/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20070716/16249161/attachment-0001.html