[cap-talk] Persistence as a category, danger, PLASH (was: as a cap value)

[Jed Donnelley]

On 3/13/2008 11:27 AM, Raoul Duke wrote:
> hi,
> 
> That doesn't totally make sense to me yet - If only considering local
> capabilites and persistence, and if the way a capability disappears is
> via entire system reboot, then the users of the capability would also
> be gone. So having it disappear isn't really anything bad or special
> since *everything* is gone and has to be restarted.
> 
> But you'd still want to issue it since if the universe doesn't restart
> you want to use it.
> 
> ?
> 
>>  Here's a "proof" (using the above thinking) that all capabilities
>>  should be persistent:
>>  __________
>>  If having a capability disappear before it's first intended use wouldn't
>>  cause a problem, then don't create/issue the capability.
>>
>>  If having a capability disappear before it's first intended use
>>  would cause a problem, then it must be issued as persistent.  (e.g.
>>  and then revoked when it's absence would no longer cause a problem).
>>
>>  Therefore in any case capabilities should be issued as persistent.

What you say above was exactly the point I was trying to
make in my follow-up message, "Persistence as a category,
danger, PLASH":

http://www.eros-os.org/pipermail/cap-talk/2008-March/010363.html

I hope you understood what I was writing there.  I
agree with you that in the case where capabilities
and the processes that possess them disappear at
the same time then there is no value added by
persistent capabilities.

Perhaps you saw Jonathan's counter argument which
I'll respond to here (taken out of context, but hopefully
still with a correct reference):

On 3/13/2008 10:24 AM, Jonathan S. Shapiro wrote:
> I do not agree.
> 
> In such systems, there is what might be called a "persistence boundary".
> This most commonly appears in the architecture as a boundary line
> between a capability-based runtime system and an ACL-based persistence
> layer. While UNIX is an imperfect capability system in this regard, it
> is an example of the type of design that I am describing.
> 
> The reason to consider capability persistence in such systems is this:
> whatever the merits or weaknesses of ACLs or capabilities, a single
> consistent permission system is invariably preferable to two mutually
> incompatible permission systems. Consistency of semantics across the
> system is greatly to be desired.

This point is very difficult for me to argue because, as
noted elsewhere, I believe the capability paradigm for
delegating authority from person to person is superior
(easier to understand, finer grained, more natural, etc.)
than the ACL mechanisms such as are used with Unix and
Windows (e.g. chmod).

However, I can understand the argument that says that
the capability model is inappropriate at the person
level (consider the criticisms that capabilities can't
meet the TCSEC requirements pre Horton - no way to
review who has access to what, no person/role based
revocation mechanism, no logging/auditing, etc.) but that
capabilities *are* appropriate at the programming interface
level (using ACLs with the IDs being process IDs seems
ridiculous - certainly I know of no system that has
used such a scheme, never mind successfully).

Such a consideration would force one into a model were ACLs
are used at the persistent people level and capabilities
at the non persistent programming level.  Most users are not
programmers, so the inconsistency should not present too much
difficult for either group.  Programmers are smart enough to
know the distinction and users need only deal with the model
that is (arguably) more workable for them.

I'm mostly playing devil's advocate here, but there
is my argument.

Let me continue with Jonathan's response to my
"Persistence as a category" message:

>> > One only needs to start considering persistence if
>> > there is some way to store capabilities between system
>> > restarts.
> 
> That is necessary but not sufficient. Storing the capabilities per se is
> actually pretty easy.

Oh?  How does one store a Unix file descriptor?  How
about a Mach "port"?  I think most of these types of
systems have no means to store capabilities - which is
why they work on some level.  It's also why, for me,
the Mach network server makes very little sense.  It
uses the same DCCS (vat) sort of distribution mechanism,
but the capabilities being distributed are not
persistent.  If the serving system reboots, the remote
capability becomes invalid.  If the remote system reboots,
the capability becomes "lost".

> The challenging part is persisting the objects
> *named* by those capabilities and the association between each
> capability and its holder.

By it's "holder" I assume you mean the subject (a
"client" process with access) and not the server?

I don't think there is a particularly novel challenge
involved in persisting the objects.  Isn't the generic
such object a "file" - which have persisted in systems
since the earliest days.  Without such persistence it
seems that systems would be nearly worthless.

So let's consider the association between each
capability and it's holder.  If both the capability
and the holder disappear when the system is restarted,
then I think we agree there is no problem?

If capabilities and processes persist (as I know they
did in NLTSS and as I believe they do in the KeyKOS,
EROS, Coyotos series), then 'all' one must do is to
make the pointer in the persistent capability point
to a persistent "object" (e.g. a file header on disk).

I can see a small challenge here, but certainly
nothing significant.  Any of us working on such
systems have (easily?) dealt with this challenge
I believe.  Maybe I read too much into that
"challenge" term.

>>   In systems with such persistent (or at
>> > least restart de coupled) capability storage I still
>> > think my argument that all capabilities should be
>> > persistent applies...
> 
> In any capability system of either type, it is necessary to be able to
> explicitly sever capabilities. In a system having a mechanism to sever,
> that mechanism is sufficient to sever capabilities on restart if
> desired.

It seems to me we are agreeing above.  Sometimes it's
difficult for me to tell...

However, with regard to "sever capabilities on restart if desired",
how is one to know if it is 'desired'?  AlanK may want to weigh in
on this, but from my perspective if there are any persistent
capabilities (justified as above), then there is no reason to
assume that the reboot of one system will be anything more
than an arbitrary point in time.  Any severing at a reboot time
therefore seems capricious and unwise to me.

I believe that any severing of capabilities should be done
for sound semantic reasons.  Namely it is known there there
is no longer any legitimate use that can be made of the
capability (e.g. what I suggested for PLASH - namely that
"capabilities" are revoked when an application terminates,
though I recognize there could be exceptions in the world
of persistent capabilities).  In the case where capabilities
only appear in processes that disappear at reboot time, then
it seems natural for the capabilities and processes to
disappear together.  Otherwise I believe they should both
be persistent and only destroyed on need.

This ties into our last point of discussion:

>> > In all systems I believe that for safety (avoided
>> > danger) capabilities that are issued to applications
>> > for temporary use should be revoked when the
>> > application completes.
> 
> This is also subtle and challenging. It depends on whether this
> revocation is transitive. In L4Sec, for example, where the mechanism of
> capability transfer is MAP, revocation of a particular capability
> location (which occurs either explicitly or through overwrite) has the
> effect of revoking all of the locations whose current values were copied
> from the location being revoked.
> 
> This type of transitive revocation raises some very challenging problems
> of recovery when a sequence of mappings A->B->C occurs and B wishes to
> exit before C does. It is a "semantics of durability" problem.
> 
> The L4 folks argue that some form of capability exchange protocol is
> necessary at any boundary between distinct revocation domains in any
> case, and they therefore argue that this issue is not significant in
> practice. On the other hand, when challenged they could not produce a
> sensible recovery protocol for certain page fault unmaps.
> 
> My sense is that the jury is still out on this issue, and it will be
> interesting to see what emerges.

How ... surprising.  L4Sec I guess is:

http://os.inf.tu-dresden.de/L4/L4.Sec/

?  Do those folks have representatives on cap-talk?

I see they say, "Special thanks go to Jonathan Shapiro for his
continuing support in building secure microkernels." at the
start of their documentation, so you must have some influence
there Jonathan ;-)

I don't recognize any other name from:

Helpful contributions to this manual came from many persons, in particular from Ron Aigner, Marcus
Brinkmann, Christian Ceelen, Norman Feske, Hermann H¨artig, Christian Helmuth, Michael Hohmuth,
Adam Lackorzynski, Jork L¨oser, Frank Mehnert, Michael Peter, Martin Pohlack, Lars Reuther, Espen
Skoglund, Udo Steinberg, Christian St¨uble, Neil Walfield, Alexander Warg, Stephan Wagner, Andreas
Weigand, and, Jean Wolter

on cap-talk.  My, what a tangled world.  Somehow it seems to me
that in this day and age we could just "have it out" and come
up with a best design in this area.  Sadly this doesn't seem to
be the case.

I guess I'll not continue my argument that revoking capabilities
granted to an application when it terminates makes sense here,
as this message is already too long.  However:

That brings me to the topic of other lists discussing capabilities
which I'll start a new thread for.  Whew.

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