Split Capabilities: Making Capabilities Scale
Fri, 14 Jul 2000 18:10:29 -0700
> -----Original Message-----
> From: Jonathan S. Shapiro [mailto:firstname.lastname@example.org]
> Sent: Friday, July 14, 2000 3:38 PM
> To: Karp, Alan; 'Norman Hardy'; email@example.com
> Subject: Re: Split Capabilities: Making Capabilities Scale
> > 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.
I don't think distributed GC is possible. That's why e-speak Beta 2.2 made
capabilities resources that ARE visible to the platform. I was a little
disappointed, because simply making the root SPKI certificate a resource
would have solved the problem. Oh well, just another example of banging my
head against the wall.
> > Our first demonstrations had clients explicitly listing the access
> > rights they wanted on each request. We were told in no
> uncertain terms
> > 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,
> > 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?
I view it as just accepting reality. Look, you've got to come to me to
access my service. I ought to do the checking then. NFS made the wrong
decision. When I export a file system r/w, I'm relying on the remote kernel
to enforce the permissions. (So I've been told, anyway; I've never looked
You can never prevent all denial of service attacks unless you unplug from
the network. (I guess that's the ultimate denial of service.) However, in
e-speak we attempted to limit the damage done at the attack points. Not
being in the kernel meant we couldn't do anything about problems with the
TCP stack. However, all our protocols minimized the time and resources that
an attacker could cause us to consume.
> 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.
Agreed. I'm simply saying that if the resource lives on A's machine, A must
assume responsibility for enforcing the rules. If A must rely on someone on
B's machine to enforce rules on A's resources, all kinds of things can go
wrong. Some of them don't even require bad behavior by B. For example, a
network partition could prevent B from releasing a lock so A can't work.
> > 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
> 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
But if you are in control, the flaw is in your implementation and can be
fixed by you. If it's under someone else's control, you've made the problem
a distributed one, and I don't believe there's a general solution.
> > 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.
I agree. In fact, our original plan was to move e-speak into the kernel or
at least provide a trampoline so we could impose our controls as if we were
in the kernel.
> The resulting fireworks were entertaining to the observers,
> at least, and I
> now work at Johns Hopkins.
I'm surprised. IBM guys usually love this kind of fight.
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-2
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278