[E-Lang] Re: Old Security Myths Continue to Mislead

[Mark S. Miller]

At 01:45 AM Sunday 8/5/01, Chip Morningstar wrote:
>Jonathan requests:
>>... I would prefer that the "Original E"
>>team discuss here their experiences with the performance of pervasively used
>>object proxies. That would be relevant, and it might help Dan's group in the
>>process.
>
>I don't recall that we ever did any serious measurements of this overhead
>(although perhaps MarkM can correct me on this point -- my memory isn't as good
>as I remember it used to be).  At least, I don't see anything in my records to
>indicate that we did that.

I'm a bit confused about the line between what the mediator pattern is and 
isn't, so below I'll try to draw some finer distinctions.  But first a word 
about measured security overheads in EC Habitats.  (And I'd expect my 
memories of the specifics here to be less accurate than at least Chip's, 
Bill's, and Danfuzz's.)

EC Habitats was an ambitious, graphically-based, fully decentralized social 
virtual system, with a capability-based distributed security architecture 
through and through.  Once the development effort was mostly logically done, 
we were dying on poor performance, so a lot of effort was put into 
instrumenting and profiling the system to spot the problems.  During this 
exercise, we identified many performance problems, some of which were our 
"fault", and some of which were Javasoft's "fault".  However, the only 
security related overhead that I recall even became noticeable under 
measurement was signature verification on initial connection handshake.  And 
it was never enough of an issue to become a priority.

Now this doesn't mean we weren't paying large overheads for security.  It 
may have simply been that other things were so much worse as to mask these.  
However, over the next months we fixed many of the worst problems we'd 
identified, and the result worked well enough that we went into a large 
scale beta with outside customers, who generally found the world to be 
interesting and fun.  It still had perceptible performance problems on the 
stock consumer hardware at the time, but I doubt any of these would still be 
perceptible on today's stock consumer hardware.  At no time was a need to 
compromise security ever raised in order to get the needed performance.


>Even now that the issue has been raised, I
>find the suggestion [pervasive use of the mediator pattern] somewhat bizarre.

For the mediator pattern as it's normally understood, I completely agree 
with Chip.  In E, W7, Joule, and Toontalk, an object is already a "protection 
domain", where I here define "protection domain" as the finest granularity 
of architecturally supported mutual suspicion.  I like this definition 
because it corresponds to the KeyKOS or EROS Domain -- loosely, an address 
space and clist combined with the ability to respond to messages (by 
executing programs in that address space).

As I understand what is normally meant by "complete mediation", it does 
indeed correspond to KeyKOS's "compartments" used to build KeySAFE, and to 
Chip's first example -- Original-E's comm-system-enforced vat boundary.  
Chip's second example involves per-type wrapping logic, but is otherwise the 
same. In all cases, we can characterize the pattern as one of growing a 
membrane. As the surface area of the compartment expands (as there are more 
object references that virtually cross the compartment boundary), the 
membrane automatically expands to cover this new area (to proxy these new 
references).  

So, for the various cases where's either tradition has actually built 
compartments/membranes, what were the performance implications?  What was 
the motivation to build this mechanism?  And what lessons may we learn about 
where else these mechanisms may be well motivated?

* KeySAFE: Has anyone measured the overhead of imposing a membrane between 
Domains?  Any idea how much this would cost in EROS?  The purpose of 
KeySAFE, AFAIK, was to meet Orange book criteria of high security.  These 
Orange book criteria, IMHO (yes, H in this case), are ill motivated.  They 
come from hierarchical military organizations and from ACL security 
thinking.  In particular, the Bell-LaPadula or star properties seems to me 
like the Ackerman's function of security: An interesting stunt, useful only 
in order to demonstrate you can do it.  In both building and dreaming of 
distributed secure applications, I've never encountered a situation where I 
needed it.

* Wrapping legacy Java (Chip's #2): I think I simply agree with Chip on this 
one.  And I don't remember this popping up as a performance concern under 
measurement.  But even if there were substantial overheads here, this 
doesn't effect Jonathan's original point -- overheads in a non-legacy 
constrained capability/object language.  In any case, I certainly see how 
this use of *incomplete* membranes is well motivated here.  Incomplete, 
because many individual Java objects already happen to follow object 
granularity capability discipline (given that certain methods inherited from 
Object are suppressed).  These safe objects can be let through unmediated.

* Original-E's comm system (Chip's #1): As Chip says, there's inherent 
overhead in the comm system for a distributed object system.  Other than the 
handshake, it isn't clear that we paid any significant additional costs for 
making a capability secure one.  Curiously, we several times started to use 
the comm system logic itself for compartment/mediation purposes.  After all, 
we've already paid all the costs to deal with network partition at vat 
boundaries, it seemed reasonable to use this for en-masse compartment 
revocation as well. However, each time we did this we found it was a 
mistake, and put the compartment boundary elsewhere; about which more below.

In any case, the mediation here is also not "complete".  Certain objects are 
considered PassByCopy (ie, data-like objects) or PassByConstruction (they 
handle the coordination between their various presences themselves).  
PassByCopy corresponds to the KeyKOS and EROS data portion of a message, 
which also passes though their membrane.  PassByContruction leads to Una, 
which is much too big a topic for this message.  Suffice it to say that it 
vastly reduced the overheads due to the network, but if the only relevant 
overhead were mediation itself, we wouldn't have bothered with Una.

* EC Habitats regions and sessions.  This is the one example I've ever 
encountered of a well motivated use of the compartment/membrane pattern for 
security.  When an Avatar entered or exited a region, its entry or exit was 
announced to all the other Avatars in that region.  While present in the 
region, an Avatar was visible to the other Avatars in that region.  We 
supported the naive intuition of a region as a private multicast channel -- 
things said in the region could be heard by those in the region at the time, 
but no one else.  To enforce this, we had to encase the Avatar and all the 
object he brought into the region in, effectively, a compartment, so that on 
Avatar exit he could not leave behind a listening device.

* Is confinement mediation?  Somewhere I think I saw someone (Jonathan?) 
refer to confinement as a case of mediation.  I certainly find confinement 
and its variants (eg, durability) well motivated.  However, going back to 
KeyKOS, capability systems achieve confinement without anything like a 
membrane mechanism.  They do it on construction by simple reachability 
constraints, which add no overhead beyond that paid for basic capability 
security.  I suppose you could view KeyKOS's Sensory keys as a kind of 
membrane, but E has no such mechanism, and confines by pure reachability 
constraints anyway.  I propose that confinement not be counted as mediation, 
or at least not be counted as mediation-by-membrane.


Bottom line: In a capability system, the compartment/membrane pattern is 
very rarely if ever called for.  When it is, it is only needed at a 
granularity vastly larger than the individual object/protection-domain.  
Therefore, the relevant overheads for a capability language are just those 
you'd expect -- the overheads already paid by any encapsulated, polymorphic, 
pointer-safe, pure-object language.


        Cheers,
        --MarkM