[cap-talk] Resource limitations (was: On revocation...)

[Marcus Brinkmann]

At Sun, 10 Dec 2006 01:50:29 -0800,
Jed Donnelley <capability at webstart.com> wrote:
> 
> At 06:52 PM 12/9/2006, Marcus Brinkmann wrote:
> >At Sat, 09 Dec 2006 17:18:52 -0800,
> >Jed Donnelley <capability at webstart.com> wrote:
> > > I admit to having a rather single minded focus in this area, but I
> > > believe this sort of focus is appropriate for a list like cap-talk.
> > > It seems to me that making changes for more explicit control of
> > > internal table space for servers falls into another area.
> >
> >I would say it depends.  It's fair enough to focus on different
> >aspects of capability based design, and one can certainly restrict the
> >application of capability design patterns to such a narrow set of
> >domains that resource allocation and certain trust dependencies (eg
> >which capabilities can be safely invoked to what end) are not a
> >concern anymore.  But I think it would still be appropriate and
> >interesting to analyse the actual limits of such contemplations.
> >
> >You and I have had several points in the discussion now where we
> >failed to agree on how important a particular design aspect was
> >because you were considering a distributed network system, while I was
> >considering an operating system architecture.  I think that if we are
> >clear on which system we are referring to in the discussion, we can
> >avoid misapplying the arguments and benefit from knowing about them
> >even if they are not directly relevant.
> >
> >If you are saying that cap-talk is only for a specific narrow type of
> >capability systems...
> 
> Certainly not.  Of course I don't set the agenda and in fact am
> a rather late comer to this list.  Naturally I consider all
> aspects of capabilities and related access control topics as
> reasonable for the cap-talk list.  However, I don't think a topic
> like scheduling CPU cycles would be appropriate.  I see the
> sorts of resource limitations that you mentioned recently
> in this light.  While issues related to costs for a particular
> implementation of responsibility tracking in capability
> delegation seem on track to me, the general topic of pushing
> resource management back to users of services seems to me
> unrelated to the core focus of this list.

Ok, I see your point.  I frankly admit that I am probably
overemphasizing this point out of my own special interest.

However, although I am not able to make this point formally at this
time, I think that resource management issues deserve particular
attention in capability systems.  This seems to me to be related to
the finer granulation of privileges that drags finer granulation of
resource management along with it.  The Mach kernel provided a
particularly brutal lesson in that regard.  Also, delegation is almost
non-existing in traditional ACL-based systems like Unix, but it is an
important design pattern in capability systems.

Last but not least, although we have the luxury to emphasize or
deemphasize particular aspects of an implementation, a malicious
attacker doesn't care and will simply pick the weakest link in the
chain.

>From my point of view (and again, this is a pretty narrow one related
to OS design), resource management questions can not be ignored in
capability systems using the same reasons why they are ignored in
tradition systems, and I think it is questionable if they can be
ignored at all in the long run.

Anyway, I will be careful not to repeat myself on this anymore.

Thanks,
Marcus