[E-Lang] defense in depth

Bill Frantz frantz@communities.com
Wed, 24 Jan 2001 17:05:47 -0800


At 11:46 AM 1/24/01 -0700, Marc Stiegler wrote:
>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.

OK, some believe we can't make the substrate perfect.  That leaves the
question, what color is the toast?  Is it light brown or burned black?

If it is only light brown, then defense in depth can help.  (If it's black,
then it's windows :)  My earlier example of Iptscrae is a fine example.
There was a flaw in the C implementation which allowed an Iptscrae program
to store anywhere in application memory.  The same flaw in the Java
implementation resulted in an IndexOutOfBoundsException.

But let met take a different example, which may be rich enough to shed
interesting light on the subject.  I run an Apache web server under my Unix
ID.  Since this server is accessible from outside the company, I have
concern about which files it can serve.  I would like to have it only serve
files from one directory tree.  I certainly don't want it serving the
source code for our products, or even the Perl code for the cgi scripts it
runs.  Under Unix, I am dependent on my use of the Apache configuration
files, and the file name checking in Apache; to provide this protection.
(And no, I don't trust myself very much when writing configuration files.)

If I were running it under EROS, I could apply the principle of least
privilege.  I would still have to give it a capability to the cgi code, but
I wouldn't have to give it access to the product source code.  That would
be a step forward.  However to protect the cgi code, I still have to trust
Apache, Perl, and my configuration file.

Furthermore, the Perl code calls a Unix command (crypto is easier to do in
C than in Perl) passing a parameter received in the post method.  This
brings up yet another set of obscure security warnings in the manuals.
(They have something to do with making sure that the data passed to the
shell command doesn't allow arbitrary command execution.  I'm not sure I
coded the Perl correctly to avoid all such attacks.)  I would hope that,
under EROS, I could define this C program to Perl in such a way that
invoking a shell was not needed.

Even if I don't change Apache or Perl, under EROS, or any other principle
of least privilege system, I can limit the files and commands Perl and
Apache can access, and get a second layer of protection for the product
source, and against arbitrary command access.


>--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.

I have my doubts.  I just don't trust PC hardware enough.  A simple error
in virtual address translation, an undetected memory or disk error, the
list goes on.  What we can hope is that these errors will cause the
substrate to stop (crash) rather than compute with bad data.