[E-Lang] defense in depth

Marc Stiegler marcs@skyhunter.com
Wed, 24 Jan 2001 11:46:31 -0700


Here are the points I tried to make at too much length before:

--If the substrate material is defective in a security infrastructure,
everything is toast.
--We can make the capability substrate perfect: it is a small enough simple
enough piece, a small number of dedicated disciplined minds can make it so.
--Given a perfect substrate, we can make amazingly complex superstructures
with surprisingly reliable security because
--With languages like E, the rate at which programmers will introduce
security breaches will go down. And the frequency with which they will
introduce security breach closures will go up. Incredibly, in E, I predict
programmers will introduce security breach closures inadvertently, as a side
effect of improving maintainability!
--Both theory and my personal experiences writing a dozen E programs with
both security issues and some modest complexity issues leaves me convinced
that, though we cannot build huge software systems with no security breaches
at all (there's just too much stuff in such a system), we can indeed build
huge software systems in which the security breaches are narrow, generally
unimportant, and none-multiplicative (getting minor breach A and getting
minor breach B does not get you to power C). These breaches would be like
the "technical" security breaches in the first version of Echat. I call
these breaches "technical" because, though there were powers granted that
shouldn't have been granted, they were silly powers (the ability to pop a
dialog box on someone's screen), not critical powers (the ability to forge
an identity, read confidential material, or modify an operating system
file).

I think people can get a first gleam of the possibilities by reading the
architectural discussion that introduces the "Satan At the RaceTrack"
example in "E in a Walnut", chapter "Secure Distributed Computing", at

www.skyhunter.com/marcs/ewalnut.html

Here, for a distributed computation problem with some modest complexity,
with a seriously motivated attacker as a participant, an architectural
approach is laid out using capabilities that is simple to understand, simple
to implement, and simple to audit. I do not believe it will take much
experience with capabilities for large numbers of system architects to
achieve this level of facility in such designs.  I believe I myself have not
screwed up a security architecture for any program I have written since that
very first one (though the only testers of this belief so far have been a
series of older and wiser marc stieglers, who have been unable to find flaw
in the designs created by younger and more foolish marc stieglers :-)


--marcs

----- Original Message -----
From: Jonathan S. Shapiro <shap@eros-os.org>
To: Marc Stiegler <marcs@skyhunter.com>; David Wagner <daw@cs.berkeley.edu>;
E Language Discussions <e-lang@eros.cis.upenn.edu>
Sent: Wednesday, January 24, 2001 10:27 AM
Subject: Re: [E-Lang] defense in depth


> > 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.
>
> Hmm. My reactions, in order, are: "ouch", "oh shit", "thanks", and "for
> small values of perfect".
>
> "ouch" and "oh shit" because if the list is this small we better none of
us
> get hit by trucks.
>
> That said, I want to add that even if we achieve what you say, it isn't
> enough. I am *desperately* trying to get out of the kernel on the EROS
> project, because the real need is to investigate how we build manageable
> user software in this world. If we are unable to translate this style of
> software into something that relatively ordinary developers can use with a
> high probability of success, we have failed. I had some experience with
this
> in the development of C++. It is part of why I am very pleased that MarkM
is
> working on E.
>
> Our real problem is achieving critical mass across the board. Development
> work is about to explode on EROS, and we will soon (i.e. in a few weeks)
> desperately need people who are willing to "pitch in", both on paid and
> unpaid basis (my apologies for the plug). If you are possibly interested
in
> doing so, please subscribe to the eros-arch and/or eros-port lists.
>
> > >There's no magic bullet (no, not even capabilities!)...
>
> Oh well. At least there is still a magic carpet and a magic eight ball.
> There is some comfort in that.
>
>
> Jonathan
>