Split Capabilities: Making Capabilities Scale

[Jonathan S. Shapiro]

> I don't understand the term "permanently retired" in the context of
> persistent objects, such as files.  "Permanently retired" implies that the
> capability will never be needed again at any time in the future.

That is what I was getting at. I did not mean capability expiration. As an
example, consider the system library (.so) files. A read-write capability is
generated for each. Once a given library is written these capabilities are
never used again. It is surprising how many files in a system are either
"initialize once" or purely temporary and short-liveed.

> While I agree that least privilege should apply to every single request,
> market pressures forced us into a more conventional model as the default.

Can you expand on this? Having never seen a capability system, the market
doesn't know what it wants in this area. I'm therefore dubious about claims
of market pressure. Sometimes the child shouldn't get the lollipop
notwithstanding how hard they may cry about it.

> We still provide a means to narrow access rights for those knowledgeable
to
> understand why the effort is worthwhile.

You have now said words to this effect twice, and I find them a source for
concern. You are tacitly assuming that my unwise choices do not impact
MarkM's ability to construct a secure environment. In connected systems this
is untrue, and it is therefore reasonable to set policy.

> > How do you ensure that when a capability is no longer needed
> > it is dropped?
>
> How do you know that a capability will never be needed again in the
future.

When the last client "forgets" that capability, it is dead and all access
lists associated with it can be killed. A new capability conveying the same
authority to the object may later be fabricated, but this has no association
with the old capability.

> Recall that a split capability is not associated with any particular
object.

I think that answers my question.