[cap-talk] Responsibility tracking: fine points: usage cases, log exposure, resource use

[Jed at Webstart]

At 03:06 AM 12/6/2006, Marcus Brinkmann wrote:
>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:

<usage cases:>

> > 1.  Any delegation between people should be tracked fully
> > as above.  These don't happen so often and I think any overhead
> > is justified.

I'll also note that at the level of human action times any
latency is certainly negligible.

> > 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).

This is also a case where a human action is often involved.
Even when not (e.g. cron, batch, etc., etc.) I think the
startup times are such that any overhead from this protocol
is likely not significant.

> > 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 agree.  However, since I know there to be at least one case
(whatever software manages delegation of permissions-capabilities
between people) I thought it was important to at least note this case.

> > 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.

I hope we'll find out.

<log exposure:>

> > > > 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.

Let me just pick up on the above statement a bit.  If you feel that the
mechanism exposes information more than necessary for correct operation,
what reduced information (logging) do you feel would be adequate?
To me it seems:

A.  Who delegated what to whom, and

B.  What was done with the delegated permissions

seems about a minimal set (to meet the needs of TCSEC folks and
to be able to at least track "loose lips sink ships" where the
intent of the actors is to follow policy).  Are you suggesting that
less information is needed?  If so, what do you believe should be
removed?

> > >It depends on
> > >your level of paranoia if you consider this to be a problem or not.

I guess I'm not so paranoid in that regard.  I believe the information
about who did what when can already be logged in our current market leading
systems.  To me the adding of delegation tracking and tying in that trail
to the records of actions improves the situation rather than making it
worse - even if I put on my paranoia hat.

> > 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.

I agree, though this isn't the case that I'm focused on.

>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,

In this case the "superuser" ia of course the "user" that runs the server.

>    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.

Whether or not it is used I think.

>    This may be a concern, but not necessarily so.

I consider it a benefit naturally or I wouldn't be working so hard
on it.

>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? :)

I hope we'll find out.

<resource use:>

> > >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.

You describe a typical denial of service attack that sadly is available
in every system that I'm aware of.

>There is no obvious way to fix that.

This mechanism is not unique in that regard I think.

>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.

Hmmm.  Of course at some point a server can simply refuse to do
responsibility tracking.  So sad, but by that point I expect that
either something is wrong or the situation is really a denial of
service attack and such a refusal may well be the appropriate action.

>Certainly good enough for "a" workable system,

Glad you think so.

>where workable does not
>include running any malicious programs (and where running a buggy
>program can be a fatal experience).

I don't consider a service refusal particularly "fatal", but I
hope to find out.

>Sounds like Unix :)

Please.  Of course the idea is that we can enable users to manage
their own delegations (without the need to invoke a superuser)
with even stronger tracking than is available in Unix or Windows
or indeed in any IBAC system.

> > >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.

Perhaps you can enlighten me on the practical problems that currently
result from this atrocious state on Unix.

> > >Potentially more secure implementation strategies (server-blind
> > >protocols).  Of course, that conflicts with some of the goals wrt
> > >identities.

Right - which is what I'm hoping to add for the needs of folks like
the TCSEC folks who criticize object-capability use as necessarily
laissez faire.

> > 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).

I don't think the resource use is any worse with anonymous delegation
through membranes, though that is not where we're trying to add value
in this discussion.

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



--Jed http://www.nersc.gov/~jed/