[E-Lang] Re: Old Security Myths Continue to Mislead
Mon, 6 Aug 2001 10:39:17 -0700
Some comments on Jonathan's note and others that followed:
We did extensive performance studies of e-speak Beta 1.0, a version based on
split capabilities, with the core mediating all requests between clients
(processes). After a fair amount of tuning effort, our round trip trivial
request time was 1 ms on a 300 MHz Pentium. Since everything was done in
user space, we had to put up with 4 context switches at 400+ microsec each.
(Our processing time was of the around 200 microsec when all clients and the
core ran within a single JVM, but that configuration is hardly secure.) Had
the context switch time not been an issue, we would have tuned the rest of
the code, but I doubt we could have gotten much below 100 microsec.
On the other hand, if we could have put the core in the OS kernel, I believe
access to a core-managed resource could have been done in a good deal less
than 100 microsec. The main overhead was hash table access to do name
resolution. We never investigated caching these lookups because other
bottlenecks dominated. Even if we had, I don't believe we could have gotten
down to a few microseconds without special casing some paths.
Even though all messages passed through the core, the core never looked at
the payloads. Hence, confinement ala Lampson was not enforced. Capability
confinement could have been enforced using a mechanism in the design that we
did not get a chance to implement.
The basic mechanism in e-speak is having a name binding to a repository
entry for a resource. These bindings had meaning only to the client, so
there was no out of band mechanism for communicating name bindings. (This
is sort of like MarkM's argument about transmitting bits isn't the same as
transmitting capabilities.) Further, in a distributed setting, all
references passed through a proxy on the machine owning the resource, and
all names were path dependent. Hence, two clients on other machines could
not communicate capabilities between themselves; all such transfers had to
pass through the proxy on the machine owning the capability, and
communication between these proxies was mediated by their core.
In general, any client could send a name binding to a resource to any other
client. However, we could impose visibility tests so that the receiving
client could not use the name binding, as explained in
http://www.hpl.hp.com/techreports/2001/HPL-2001-164.html. The unimplemented
part was what we called "grant authorized" resources. Name bindings for
these resources could only be transferred by clients holding the "grant"
capability. I believe these mechanisms provided all the capability
confinement anyone could want.
Revocation was an essential requirement for the design of split
capabilities. Since clients only had name bindings to resources, and
capabilities were just resources, we had several ways to revoke a
capability. One was removing the binding from the client's name space, most
often used to revoke a capability granted to a remote client. Another
involved removing the capability from the e-speak repository. (We used
clones of capabilities for selective revocation.)
I've heard many knocks against the *-property as being irrelevant to
anything but rigid military structures. However, every company I've ever
heard of has both classification levels and compartments. While this
approach may have been copied from the military, they provide business
value. I can't imagine businesses wouldn't like a system that made managing
access manageable. With split capabilities, we were able to configure these
policies and others by simple configuration of the permissions.
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-3
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278