In article <3A702C2D.582F9BF9@cs.jhu.edu>,
Jonathan S. Shapiro <shap@cs.jhu.edu> wrote:
>Defense in depth has clear applications. I think the essence of the
>point that people here are trying to make is that capabilities make it
>possible to structure applications in fundamentally better ways. Having
>done so, most of the currently applied types of defense in depth become
>irrelevant.
>>To put that another way: most of the methods for defense in depth that
>are deployed today exist to patch around fundamental failings in our
>ability to structure programs correctly.
Thanks for stating it so clearly. It makes it easier for me to respond
with my objections.
Defense in depth is deployed because we are unsure that we can build
perfectly secure systems. Now, one might call it a fundamental failing
in our ability to write secure programs, but I do not think that this
will be solved by capabilities. Languages like E might go a long way
towards helping structure programs better, just like Java went a long
way towards helping people write secure programs (vs. C). But I don't
think anyone on this list claims that all programs written in E will be
perfectly secure (please correct me if I'm wrong).
>Defense against/recovery from user error clearly does not fall in this
>category. MLS enforcement clearly does not fall in this category. Stack
>introspection, to my mind, *appears* to fall in this category, but I do
>not completely understand stack introspection, so take that with a grain
>of salt.
My understanding is that stack introspection, as it's used in Java, is
not a method of "defense in depth"; it's a method of defense. If one
turns off stack introspection, the Java security model is now completely
broken. It's somewhat nonsensical to name any one method of protection
as "defense in depth", since defense in depth is a strategy of combining
several protection methods.
- Nikita