<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Jonathan S. Shapiro wrote:
<blockquote cite="mid1184617150.30051.79.camel@vmx.eros-os.org"
type="cite">
<pre wrap="">On Mon, 2007-07-16 at 11:28 -0700, Jed Donnelley wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap=""><!---->
The argument contains a flaw:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
I think perhaps the issue is more a lack of clarity in my description of<br>
the argument. When I say "any computers that had access to the<br>
network would have access to what amounts to capabilities as data<br>
for any capabilities that are distributed on the network." I didn't<br>
intend to imply that computers which could "snoop" the network<br>
traffic would get access to the permissions provided by the<br>
serialized capabilities, but rather that when any computers on<br>
the network properly received such serialized capabilities<br>
(e.g. across encrypted communication facilities), they would<br>
then be dealing with what amounts to capabilities as data.<br>
<br>
Does that answer this?:<br>
<br>
<blockquote type="cite">
<pre wrap="">
So this assumption seems transparently wrong. What am I missing here?
</pre>
</blockquote>
<br>
<blockquote cite="mid1184617150.30051.79.camel@vmx.eros-os.org"
type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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?
</pre>
</blockquote>
What I am arguing here is that once you launch a capability out onto
the network, even<br>
if you use end-to-end encryption of the channel, you have effectively
no control over<br>
the computer that receives such a capability. It may be a capabilities
as descriptors<br>
system where the capability is essentially emulated for remote
execution (e.g. along<br>
the lines of DCCS or MarkM's vat system) or it may just deal with
whatever serialized<br>
form of the capability it receives and try to make use of it. From the
viewpoint of<br>
the domain sending the capability the relevant receiving domain of
trust at the other<br>
end is the whole computer system, not just what might be imagined as a
single<br>
confined domain. This is another case where I think the technique of
imagining<br>
communication to an extra terrestrial "intelligence" identified only by
a public/private<br>
key pair may be helpful.<br>
<br>
Consider a system on a network communicating with MarkM's vat
implementation.<br>
Such a remote system may choose not to run E or anything like it and
may just<br>
try to make use of the permissions granted by knowing the serialization
protocol.<br>
That is a choice that's available to any such computer on the network.
It may<br>
spray any data that it receives and may proxy any permissions that it
receives<br>
anywhere on the network (available to it through firewalls and such of
course).<br>
It is only constrained by it's reputation and the network connection it
has. This<br>
is all I was trying to suggest the argument was that was made for
capabilities<br>
as data for NLTSS. The argument was that there seemed to be little
value<br>
in permitting processes (domains) in a single system to have less
authority<br>
to act as a full partner in the serialized capability communication
protocol<br>
that computers on the network have.<br>
<br>
The argument that I believe was still valid but that I failed to
adequately<br>
defend was that there is added value in providing more limited ability
to<br>
communicate in local processes (domains) - namely "confinement"<br>
that limits communication of such processes to POLA as per the<br>
capabilities that they receive/have. Specifically that by so doing we<br>
can have better control at limiting the opportunities for programs<br>
that may be less than trustworthy from sharing any data and/or<br>
permissions that they receive from other destinations on the network.<br>
<blockquote cite="mid1184617150.30051.79.camel@vmx.eros-os.org"
type="cite">
<pre wrap="">
Jed: can you shed some light here?
</pre>
</blockquote>
I hope the above does. Thanks for taking time to consider the argument.<br>
<br>
--Jed <a class="moz-txt-link-freetext" href="http://www.webstart.com/jed/">http://www.webstart.com/jed/</a><br>
</body>
</html>