[E-Lang] defense in depth
Thu, 25 Jan 2001 10:44:05 -0700
David, we have here a misunderstanding. I was not attempting to claim that
my little web server proved you could do it all the same way and have it
better using E and capabilities. A better statement of what I was trying to
say was, "if you're willing to forsake the currently accepted tools and
doctrine, and ask the questions fresh and adopt new answers, you can do
better." But you're right, I don't have code to prove it.
One of the things a real capability system requires is refactoring which
pieces of software have/depend-upon what powers. This is why we can't just
pick up Microsoft Word and land it on EROS and have it run swimmingly while
severely limiting the powers it holds.
Bill said he wanted to protect the source code of the Perl scripts from
visibility. But the current Web servers hold complicated bundles of powers,
bundles which are inappropriate not only from a capability security point of
view but also from a simple modularity/componentization point of view.
Apache itself, mod-Perl or whatever, actually runs Perl scripts, so of
course it must have access to the scripts, so it is possible for Apache to
leak those scripts. I'd hate to try to do the security audit of Apache to
prove the script sources are inaccessible from outside.
In today's world, the complex bundling of capabilities in Apache makes good
sense for several reasons, two of which are, no one places value on
unbundling capabilities, and second of all, the tools for componentization
are still too crude and primitive. As Bill described, putting Apache in a
capability OS like EROS buys you some seriously valuable benefits, but not
all of them. To get the rest, you have to do more serious stuff.
E makes rethinking unbundling capabilities more valuable, and at the same
time it supplies better tools for recomponentization through distributed
computation. My little E Web Server, crude as it is, does demonstrate this
point. I have recomponentized the functionality from an Apache/Perl system,
with the E Web Server serving a simpler function, and the Perl functions
being served by separate services connected by secure comm lines. The setup
of the separate service involves about 3 lines of code. Proving that the
sources for the service scripts cannot leak through the E Web Server, inside
a capability-secure environment, would be like falling off a log, even if
the E Web Server were expanded with all the other standard Apache features
like virtual directories and such. It would be like falling off a log
because, with the simpler, componentized functionality, the principle of
least authority can be applied to reduce the capabilities the web server
itself actually requires.
Apache, while it is a big complicated bundle of stuff, is not nearly so bad
as StarOffice, the filemanager/word processor/spreadsheet/web browser
all-in-one capability feast. To run StarOffice as it is bundled today, you
have to give it just about every capability you own, it practically has to
be a part of your TCB. No benefit can accrue to putting bundles like this
into capability systems. You have to ask a different question to get a
----- Original Message -----
From: David Wagner <email@example.com>
Sent: Thursday, January 25, 2001 1:27 AM
Subject: Re: [E-Lang] defense in depth
> Marc Stiegler wrote:
> >Totally off the topic you were pursuing, with E it is amusingly possible
> >do better than this if you're willing to forsake Apache. I actually wrote
> >itty-bitty Web Server in E with one special feature: [...]
> I'm glad you are willing to test the hypothesis that E allows
> you to build more secure systems (and test it on applications
> of considerable practical interest).
> However, I'm not convinced that this test tells us very much.
> No matter what language you use (capability-based or not), it
> is very easy to write a webserver that is probably very secure,
> if you're willing to give up all the features that you'd find
> a deployed webserver like Apache. Those features are perceived
> as fairly critical for widespread adoption, but they are also
> what adds complexity and makes it hard to build a high-assurance
> webserver, so comparing a stripped-down webserver with Apache
> is comparing apples and oranges.
> A better test, in my mind, is whether one can support similar
> functionality as Apache, but with a higher level of assurance,
> by implementing appropriately in a capability-based programming
> environment. Has anyone carried out such a test?
> e-lang mailing list