[E-Lang] Java 2 "Security" (was: Re: Welcome ChrisSkalkaand ScottSmith of Johns Hopkins)

Mark S. Miller markm@caplet.com
Fri, 19 Jan 2001 22:48:27 -0800

At 09:40 PM Friday 1/19/01, Scott Smith wrote:
>Looking at my question from the other end, isn't it always good to have
>more layers of security if they are truly in different dimensions? 
>[...] 1000 times more secure [...]

Most of what I know about security I learned from Norm, and the answer to 
this question especially so.  As always, I've probably garbled it from the 
way Norm would put it.  credit->Norm, blame->me.  Norm, feel free to clarify 
& correct.

The physical world is full of continua and non-local effects and such.  As a 
result, there's no such thing as a perfectly impenetrable barrier.  Physical 
security is based on barriers that resist attack, or counterattacks that 
deter attack, but there's nothing available that can prevent a successful 
attack. Defenses and attacks are quantitative matters, and defense in depth, 
thicker walls, redundant walls, belt and suspenders, all lead to increases 
in security.

In the computational world, these intuitions have some applicability to 
defending against cryptanalysis or electrical attacks, but otherwise they 
lead us astray.  In the computational world, we know we could build a 
perfect defense, but for our own confusion and stupidity.  Our greatest 
threat is not that our attacker will mount a larger attack, it is that we 
overlooked a bug in our own defenses.  If we haven't overlooked any bugs, it 
matters not how great an attack our enemies mount, we are invulnerable.  If 
we do have a critical security bug, then once an attack that exploits it is 
posted to the internet, we can be destroyed by a flea.  Very little about 
computer security is quantitative.

Our best defenses against our own confusion are simplicity and modularity.  
Ideally, for any modularly separate security issue, there should be *one* 
non-redundant mechanism that we have a hope of understanding.  In 
computation, redundant defensive walls are never copies of the same wall, 
because no one would think that is stronger.  Rather, they are walls of 
different types, like your capabilities + stack introspection, that make the 
system larger and harder to understand.  Worse, this redundancy leads to the 
old vaudeville act: "I though you were handling that case."  "What?  I 
thought you were handling it."  Ideally, good separation of concerns should 
make it clear what *one* mechanism is supposed to handle any individual 
problem, and that mechanism should take care of it perfectly.

Of course, we will still have bugs, but any effort spent building redundant 
wall would have been better spent debugging.

Note: I am not arguing here against stack introspection + capabilities, or 
stack introspection + ACLs.  That will wait until I see a concrete secure 
language design (for which Java doesn't count).  I am instead arguing 
specifically against the perspective quoted above.