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

[Jed Donnelley]

cap-talk,

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 was that:

1.  If we did capabilities as descriptors we would still need
to implement a serialization protocol (e.g. along the lines
of the DCCS:

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

) or the Mach network server or MarkM's vat implementation
to allow capabilities to be communicated more widely
on the network.  It should be noted that NLTSS was
a network operating system design from the beginning:

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

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.

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.

I still think of this argument (I'll attribute to John Fletcher:

http://www.llnl.gov/vcm/interviews/john_fletcher_1.html
http://www.llnl.gov/vcm/interviews/john_fletcher_2p1.html

) as rather forward looking for that time period of 1978
in that in today's environment of the Internet with many
millions of personal computers on an open network, that
argument is of course much, much more compelling.

Still, I do believe the above misses the base value of confinement
as being useful in protecting against potentially misbehaving
programs and generally in the context of being as POLA
as possible (including the permission to communicate
with the designation and permission to access an 'object').
Considered from a network viewpoint such confinement might
be thought of as an easy sort of local firewall for domains
(processes).  The main value from the viewpoint of an OS
running programs is that the programs can be run with effectively
limited access (e.g. to access remote network resources,
to share data on the network, etc., etc.).  The fact that
such capabilities (permission tokens) may show up in
serialized form on the network and perhaps in computers
with questionable protection seems to just be an inevitable
consequence of networking.

While I no longer agree with that argument for capabilities
only as data, I'm still quite sympathetic to the basic ideas in
the argument, so I mention it in case it might prove useful to
others.

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