[cap-talk] Capabilities giving up control vs. The status quo?

[Jed Donnelley]

I wonder if it might help some to come at this
discussion from the other side, that of the
status quo.

I would like to argue that today's market leading
systems - Unix (inc. Mac) and Windows - do quite an
effective job of keeping control of delegation.

Consider the communicating conspirators problem
that we argue is present in these systems despite
any efforts to the contrary.  There is certainly
ample opportunity for communicating conspirators
in today's market leading systems!  Every program
that we run on these systems is completely unconfined
(can communicate on the Internet) and has access to
all our authority as users.

How much of a practical problem is there from
communicating conspirators?  To be sure, one can
argue that the various forms of Trojan horse
(viruses, etc.) that plague our systems these
days are exactly communicating conspirators.

Those who argue for the status quo, however,
make the following argument (which I think is
along the lines of Toby and Duncan's section
1.2):

At least any potential loss of authority is
temporary in the sense that if we can fix
any broken code (and ACLs?) and restart our
systems then the problem is resolved.

We know that in Unix, open file descriptors
can be communicated through pipes.  If you
have a conspirator (or just a buggy program)
that inappropriately delegates such a file
access, at least (those arguing for the
status quo say) the next time the system is
rebooted the problem disappears.  Fix the
code and reboot and the problem is fixed,
permanently.

I believe this ties into the notion of
persistence in capability systems.  The
Mach system, for example, can be argued
is a capability system, but it is a non
persistent capability system.  Because of
this, anything like the Distributed Capability
Computing System implemented in Mach (as per:

R. D. Sansom, D. P. Julin, and R. F. Rashid. Extending a
Capability Based System into a Network Environment. In
Proc. 1986 ACM SIGCOMM Conference, pages 265–274,
Aug. 1986.

) is of limited value because any authority
shared over the network by such means is
reset when the system is rebooted.

This means that Mach (as with Unix) can
effectively hide it's underlying capability
nature via it's non-persistence.  They can
argue that there is no fundamental loss
of control of delegation in that everything
will be fine again after the next system
reboot as long as the code is all correct
and safe.  ACLs uberalles.

Of course I've never seen this argument made
publicly, but I believe it's there implicitly
in the design decisions for these systems.


In an odd and what I regard as a somewhat
dishonorable way I think this reasoning can
be used to argue for object capability
delegation for the network - even if you
accept that it has a problem at the operating
system level.  On the network we want "mash-ups"
that work, and continue to work despite any
rebooting of any component systems.  I don't
think this will fly, however, for those concerned
about the loss of control that the reviewer
of Tyler's paper mentioned, because they
would argue that eventually all component
systems will be rebooted with better (if
not fully correct) code, and we at least want
things "fixed" (destroy inappropriate delegations)
at that time.


So where does this leave us?  One might almost
think that our only option is to do as with
AlanK's Client Utility (I hope I'm remembering
correctly) and have every delegation be done
by proxy.  This approach might have horrific
performance properties back and forth across
the network, but is it "best" in some sense?

I argue no.  This is where I think Horton
or Horton-like mechanisms can come into
play.  As long as system designs can
incorporate what Alan refers to as a
Policy Decision Point into any delegation
that might be of concern (e.g. delegation
between "user"s, delegation between
classification levels, delegation across
the network, etc.), then I argue that you
still have the ability to exercise any
needed control.  To be sure one must
use at least a kind of "confinement" to
insure we keep these PDPs in place, but
I don't think this need be as difficult
as perhaps some (e.g. Toby and Duncan?)
imagine.

For example, consider MarkM's "vat" system
(which in my mind I think of as like DCCS).
Before any active object (subject/process) on
one system can delegate authority to one on
another system, we can arrange things so
they have to go through such a PDP.  The
initial capabilities through the vat system
can insure this.  Of course we can still have
communicating conspirators using other
communication means (if such off machine
communication is somehow available outside
the vat mechanism) and not authorities
as capabilities managed by the vat mechanism,
but those sorts of problems exist in today's
systems in any case.

Does this solve our "loss of control" problem?
I believe it does.  If there is a "loss of
control", it must either be local or remote.
If it is local, fix the code (or persistent
capability references as with fixing ACLs
in today's systems) and reboot.  If it is
remote, we can manage (control) it through
our PDP.  To be sure, this may not be
particularly convenient (e.g. the point that
I conceded to Toby about revocation through
a PDP with limited policy information
sometimes being too gross), but the control
is not lost.  Safety, auditing and logging,
etc. can be assured.

This seems to me a rather complex argument
to make to Tyler's reviewer, but I believe
that until we get this argument widely
accepted in the computer science community
we will continue to face such resistance
(papers not accepted, systems not purchased,
etc.) and will make no substantive progress.

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