[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.
Cheers,
--MarkM