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

[Marcus Brinkmann]

At Sun, 10 Dec 2006 02:57:15 +0100,
"Valerio Bellizzomi" <devbox at selnet.org> wrote:
> 
> On 07/12/2006, at 9.33, Jed Donnelley wrote:
> 
> >At 02:03 AM 12/7/2006, Neal H. Walfield wrote:
> >>At Wed, 6 Dec 2006 23:17:12 -0600,
> >>Karp, Alan H wrote:
> >> >
> >> > Marcus Brinkmann wrote:
> >> > > 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.
> >> > >
> >> > The server can always refuse if a given capability has been delegated
> >> > too many times.
> >>
> >>Sure.  But how can it do this without potentially denying legitimate
> >>service?  I think that any limit will be arbitrary and will fail to
> >>stop illegitimate use but block some legitimate uses.
> >
> >This sort of thing happens all the time in today's systems and it
> >is very far from being considered among the most important problems
> >with such systems.  There are limits like the number of processes,
> >number of inodes, not to mention of course more "legitimate"
> >resource limitations like memory and disk space.  Any exhaustion
> >of such resources result in denying legitimate service.
> >
> >How would an exhaustion of table space for delegations differ
> >from such situations?
> 
> I didn't read this before, but hey, either we have a limit in the number
> of delegations, either we have a limit on table space, in any case
> unlimited delegation is not possible.
> So where's the difference?

The difference is where the policy is set.  In the kernel-limit case,
the kernel sets a fixed system-wide policy.  In the server table case,
it is the server which sets the policy.

In the system I am contemplating, delegations are allocated from the
resources of the principal which receives the delegated resource.  In
that case, neither the kernel nor the server do need to care about
delegations, as they are not affected by them negatively.  Policy is
set at the level where the decision is made to delegate, which seems
the right place to me (one of the experiences of operating system
design in general is that separating policy and action leads to
inefficient policy decisions, see for example Stonebraker "Operating
System Support for Database Management").

L4.sec is a proposed system where this proper accounting is done for
the memory resources, but not always for CPU resources: unmap() will
potentially be accounted to the unmapper (ie, the principal which is
delegating).  The hypothetical "third alternative" I have mentioned in
my reply to Jonathan does not have this flaw (but unfortunately that
alternative does not optimize the common case, so it may not perform
well).

Thanks,
Marcus