Split Capabilities: Making Capabilities Scale

[Jonathan S. Shapiro]

> If capabilities [cannot be seen or are] hidden from the platform, as
> with SPKI certificates in e-speak DR 3.0, you can never be sure that there
> isn't an outstanding capability or that one won't be generated in the
> future.

This is an important point, and one that KeyKOS/EROS don't need to deal
with. In E, the issue is limited to SturdyRefs (if I understand matters). I
don't know if markm has plans for distributed GC or not.

> Our first demonstrations had clients explicitly listing the access
> rights they wanted on each request.  We were told in no uncertain terms
that
> requiring this level of detail from users would be unacceptable.  Perhaps,
> if we'd focused on building tools to make it easier, ...

Yep. This definitely needs to be encapsulated by the applications.

> > 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.
>
> E-speak access control is based on a couple of principles.  First of all,
I
> don't give a hoot about your resources, and you shouldn't rely on my to
> doing anything to protect them.

Umm. Err. Urgh. This is a surprisingly faithful description of how the
internet approaches the problem. Given how well that system has done
recently, perhaps you'ld care to comment on how you propose to deal with
denial of service issues given the model you seem to have?

Observation: if two parties share a multiplexed resource, and party A
requires *any* use of that resource to operate correctly, it is obligatory
that the system be able to constrain utilization by party B (or other
parties) or (equivalently) guarantee a share to party A. Any other state of
affairs is simply an incorrect installation that happens to work when not
faced with adversity.

> Secondly, if I whisper a secret to you, and
> you blab it to the world, I'm out of luck.  No middleware in the world can
> help.  I believe Mark would agree.

We would all agree about this part.

> If you give me the right to do something, I may use that right improperly.
> There's nothing you can do except not give me the right in the first
place.

I agree with this statement, but where resources are multiplexed it isn't
this simple, and some story about availability and/or QoS becomes necessary.
If I give you access to a disk block, but build the system in such a way
that others can starve your ability to manipulate that block, there is a
flaw.

> Set all the policies you want, but if you can't enforce them, what's the
> point?

Precisely the statement I made at IBM. Unfortunately, I attached this
statement to a recounting of the Harrison, Ruzzo, Ullman results about
access control lists (which provably don't constraint access right
transfer). I then suggested that putting band-aids on sucking chest wounds
wasn't a viable mid- or long-term strategy, and it was time to build a new
OS that could carry us for the long haul.

The resulting fireworks were entertaining to the observers, at least, and I
now work at Johns Hopkins.


shap