[E-Lang] defense in depth
Wed, 24 Jan 2001 10:20:20 -0700
My first question is, what is isaac.lists.e-lang, and how did this become
the discussion group rather than firstname.lastname@example.org? My Outlook Express was
unable to reply-all to this thing (I guess it's a newsgroup not a mailing
list). So I posted this reply to e-lang and David; David, if there is
someone on the newsgroup who would be interested who is not part of the
e-lang group, I request that you forward this.
My comments are embedded.
David Wagner <email@example.com> wrote in message
> Marc Stiegler wrote:
> >The bad news for the virtual world: For a given kind of wall, once
> >has broken a wall of that kind, the cost of breaking that kind of wall
> >approximately to zero.
> This, of course, only increases the importance of defense in depth.
What a delightfully intriguing alternative interpretation of the analogy!
Actually, what it calls for, if you can't get perfect and near-perfect
walls, is vast numbers of walls like swarms of bees, discarded when they are
broken because, once they are broken, they confuse the defenders more than
they confuse the attackers.
Anyway, the news with capabilities is better than the analogy. If
capabilities are used with the Principle Of Least Authority (a principle
that is trivially easy to follow most of the time in a capability language
like E-- in an E-like capability infrastructure, application of this
principle is largely a logical consequence of clean modular design), you do
indeed get defense in depth, at the swarm-of-bees density, with no cost in
complexity because it is indeed just a result of good architecture:
basically, even if you penetrate the defenses and get one capability, it
helps you not at all to get others, because the principle of least authority
ensures that getting the next capability will be just as hard. This is
considerably different from the firewall (and Java Security Manager current
browser implementations) philosophies, which are like eggshells: break the
shell, eat everything inside.
The Echat example/tutorial program, which you can find at
includes a complete security audit at the E level, and I think a careful
examination can make the point better than my abstract discussion can. The
closest thing there was to a security breach in the version that I wrote as
my first practice E program, with absolutely no consideration of security at
all, was a place where I had violated the principle of least authority.
> >The good news for the virtual world: mathematics tells us there are walls
> >you can build that are "near-perfect and perfect", [...]
> This may be true of crypto, but crypto is only a small piece of the
> puzzle. Steve Bellovin counted CERT advisories over the past decade
> and found that at most 15% of them go away if you assume perfect crypto
> deployed everywhere. The rest is a matter of good systems design and
Crypto is not the only place where near-perfect walls can be built. The
other place where even more perfect walls can be built is in object
referencing. Even Java has a probably-perfect implementation of an object
reference that cannot be reached except by a grant of the reference, i.e.,
the object references look for all the world like perfect capabilities.
I have become convinced that the underlying material of capability
security--the capabilities themselves--can indeed be made truly perfect. To
make them perfect, you must have them implemented by people like Norm, Bill,
Jonathan, and Markm. There are not many people like them in the world, but
the good news is, there are enough of them to make a perfect OS kernel and a
perfect language kernel. Given the os, the language, and the crypto, we have
enough to build everything else for secure distributed computation in the
presence of mutual suspicion, with the
> high quality software, and in that regime, our walls are decidedly
Very true, our walls are decidedly imperfect. But mostly very true because
current walls are built on top of sand, i.e., they are built without
capability infrastructures beneath them.
>There's no magic bullet (no, not even capabilities!), and
Perhaps you are correct that there is no magic bullet. But sometimes there
are magic bullets, and their magic is difficult to perceive because the
bullets are so unlike anything we see in the day-to-day world. And we live
in a world where, for the last 20 years, we have seen nothing in the
day-to-day world to suggest that there is hope of computer security.
I am reminded of arguments I used to have with socialist friends of mine
over the quality of grocery stores in the Soviet Union. I would say that the
only reason the stores are empty is that there is no free market. They would
snort in disgust and say, "there's no silver bullet". Well, in fact, the
free market was a silver bullet. It still is. Of course, today, most of the
people I used to have the argument with would say, "well, of course free
markets make the difference, it was always obvious they would" :-)
It will be interesting to see, 20 years from now, when we are all running
capability security, whether we look back into these archives and are amused
at my foolishness for thinking capabilities were silver bullets. I think
they are. I yearn for an infrastructure in which my belief can be tested.
Having said that, I do agree with defense in depth in 2 ways that I have
stated earlier, but which I have not highlighted as agreements with your
point, so I shall highlight them now:
--defense in depth through principle of least authority with capabilities,
discussed here, and
--defense to a depth of 2 for things that are directly manipulated by
humans, because of the problems with human error, and the need to be able to
survive the "Ooops!" experience.
> You seem to suggest that we have a decision to make between defense in
> depth with imperfect defenses or a single but perfect line of defense.
> But that's not the choice we are given today. If you start from the
> premise that all of our defenses are imperfect---and this seems to be
> hard to dispute---then it seems that adding multiple redundant lines of
> defense can't hurt and can only help.
But, as pointed out by others on the list at greater length, it can indeed
hurt, because the defenders get confused about what part of what wall was
trying to defend what thing. Another thing that is different in the virtual
world from the physical world is that complexity works in favor of the
attacker. Thus, this is another advantage of capabilities: in E there is
often no overhead for increasing security, it just happens every time you
modularize the design. And when you see a security flaw in an audit that
lives despite the existing modularity, the answer is usually just further
modularization. I urge you to write a few E programs to see how true this
is...and of course, the limits to its truth :-)