[cap-talk] On revocation and the use of wrappers and In Defense of Identities

[Marcus Brinkmann]

At Tue, 05 Dec 2006 18:16:44 -0800,
Jed at Webstart <donnelley1 at webstart.com> wrote:
> I think in practice the 'cases" are few and manageable.  I believe
> that:
> 
> 1.  Any delegation between people should be tracked fully
> as above.  These don't happen so often and I think any overhead
> is justified.
> 
> 2.  I also believe that when a person initiates almost any program
> to work on their behalf then such tracking with revocation should
> be used (revoking the "membrane" when the user feels the
> program is no longer useful - e.g. after it exits but possibly
> before).  One case that doesn't quite fit into the above is where
> a person wants a program to help them delegate permissions
> more permanently (e.g. their "shell" or something like to effect
> what amounts to "permanent" [after exit]) transfer of permission.
> That case needs to be handled separately and carefully.

The thing is that I am not sure if such a latter case exists (in any
significant quantity).  I think the answer may be "not necessarily",
but it is difficult to assess, because the reason why is different for
every specific case I come up with.

> 3.  I believe that any further delegation by running programs
> can and should almost always just delegate directly
> (directly communicate a capability) without responsibility
> tracking.  I don't believe further tracking is needed.  The
> "membrane" will take care of revocation after the program
> finishes, so why bother to track/log communication between
> program modules (e.g. at the E module level)?

A good list, and it coincedes with what I have come up with so far
nicely, with the exception that I think that if one has efficient
mechanisms for delegation, it may be simpler to drop case 3 and just
fold its uses into case 2.

> > > Furthermore (and this is where the new mechanism that I've
> > > been discussing comes in) the permission that Bob
> > > receives is labeled (at the server, Frank) as being delegated
> > > from Alice to Bob.  The permission that Carol receives
> > > is labeled as having been delegated from Bob (and before
> > > that from Alice).  And finally, the permission received by
> > > Bob is not available even to Alice.  When Bob invokes
> > > this permission the invocation can be distinguished and
> > > labeled as from Bob as delegated from Alice (even if
> > > Bob might proxy it or further delegate it with or without
> > > identity tracking).  Similarly when Bob further delegates
> > > to Carol.
> >
> >This is just a fine point, but worth noting: This scheme seems to
> >expose much information about the users of a service, much more than
> >seems to be necessary to enforce correct operation.  It depends on
> >your level of paranoia if you consider this to be a problem or not.
> 
> There is also the question about exposes to who.  Who gets access
> to the server logs?  I'm willing to invoke a "superuser" at that point, though
> it might be worthwhile to work out a more distributed mechanism
> for making logs available.  E.g. if I delegate to you I can access
> the logs for what you do to what I delegated.  That is what I would
> have if I delegated to you by proxy.  However, I can understand that
> you (Bob) might not be inclined to collaborate with me (Alice) if you
> knew that I could see the log of every access that you made to the
> permission I delegated.

If the system is sufficiently flexible, services will rarely be
implemented at the system level, but at the user level, and we will be
talking about two cases:

1. The server runs under the authority of the user, and the clients of
   the service are just delegates of the user with reduced permission.
   In this case, the information leakage is not a concern.

2. The server runs under the authority of a user, and is used by other
   users.  This is the case for collaboration.  In this case, the
   super-user argument does not bite, however, a weaker argument may
   apply: Users of a service need to be aware that all users of the
   service can be tracked if this delegation mechanism is used.
   This may be a concern, but not necessarily so.

There is also the further consideration that unwanted or unnecessary
information leakage, even if harmless, seems to indicate a design
flaw.  Often, such fine points generate a lot of traction if they are
viewed under a system design perspective.  Or in other words: Who am I
to compromise? :)

> >Also, this concept raises serious questions about resource accounting,
> >if you care for that.  The bookkeeping that Frank is doing needs to be
> >stored in real memory, which should ideally be paid for by the clients
> >to prevent DoS attacks.  But working that one out is tricky at best.
> 
> I'm willing to accept the Unix approach on this one (which I note
> others have denigrated), that is sweep it under the rug.  Assume
> that the resource costs for the tracking are generally small relative
> to the costs for the objects that they track access to.  As with Unix
> (e.g. the many small files case) this may not be true, but it's probably
> true enough for a workable system.

The problem is that it is easily exploitable, because the amount of
memory used to store the bookkeeping data is not bound by the number
of objects, but by the number of delegations that take place.
Depending on the design, either a user alone or at least two
conspiring users can probably exhaust these resources by delegating
the same object many times.

There is no obvious way to fix that.  You could have a quota system,
but that would need to be implemented in each service, and, well,
would suck.

A similar attack exists on current L4 implementations: A user can
simply map the same page of memory many times between two address
spaces and thus exhaust the memory reserved by the kernel for page
tables.

Certainly good enough for "a" workable system, where workable does not
include running any malicious programs (and where running a buggy
program can be a fatal experience).  Sounds like Unix :)

> >The L4 people are struggeling with it, and came up with some solutions
> >at the kernel level, which is actually the simpler case IMO, for the
> >same reason that the EROS space bank gets away with it: In both cases
> >we are talking about an entity that has complete control over the
> >required resource already.  If Frank is anything but the memory server
> >it is a lot harder.
> 
> Whatever works I say.  I think generally people (programmers) don't
> want to deal with these issues, so I go along with that approach
> as I don't think it causes any practical problems (e.g. hasn't in
> current systems).

I beg to differ on that one.  Resource management on Unix is in an
even more atrocious state than permission management.  It is true that
many people don't want to deal with either issue, but that is because
no practical solutions are widely available.

[...]
 
> >Potentially more secure implementation strategies (server-blind
> >protocols).  Of course, that conflicts with some of the goals wrt
> >identities.
> 
> Hmmm.  Any server must of course be aware of requests that are
> being made to it.  It can't be blind any more than that.  Are you asking
> that the server be "blind" to 'who' is making the requests, but still at
> the same time log 'who' made the requests?  That does seem to be
> asking a lot.  I'm not sure that is even possible.  Perhaps others
> can react.

I assume no identity tracking.  If there is identity tracking, then of
course the issue becomes moot.  But if there is not, revocable
delegation and even membranes seem theoretically possible without the
server knowing about it, by encoding the permission in the capability
name and providing kernel mechanisms (or in the network case,
cryptographic means) to reduce them unilaterally when doing a
capability delegation.  Of course, there are some costs attached to
this solution (namely, the capability names themselves become more
expensive, which may be prohibitive at the kernel level, but
acceptable at the network level).

Thanks,
Marcus