[E-Lang] defense in depth

David Wagner daw@mozart.cs.berkeley.edu
25 Jan 2001 20:12:05 GMT

Jonathan S. Shapiro wrote:
>David Wagner wrote:
>> I have to admit: Now I'm curious.  Which features of Apache are
>> inherently insecure?  Can you give any examples?
>The entire notion of CGI scripts as currently formatted. On request from
>the system administrator, Apache will gleefully punt responsibility for
>security to some other program whose environment is not under the
>control of Apache.

But that's not a bug in the requirements; that's a bug in the
implementation.  There's nothing fundamental about the notion of CGI
scripts that is incompatible with security.

You could certainly imagine secure implementations of the CGI script
notion.  For instance, if we had a perfect sandbox, one could run the CGI
script in a sandbox.  Or, if the administrator trusted the CGI script,
and if we had a perfect way for managing this type of trust, we could
ensure that we only run trusted CGI scripts.  And so on.

With today's technology, it seems likely that any implementation of
CGI scripts will be risky.  But as far as I can see, that's not because
the very concept is fundamentally insecure.

>Also, module configuration is designed such that the introduction of one
>module can alter the environment perceived by a subsequent module, and
>the current interface specification practice does not allow the
>administrator to fully understand the resulting dependencies.

Yes, I see.

But in this case it probably helps if one thinks about why modules
were introduced.  As far as I can tell, it seems to be that the real
requirement is ease of extensibility.  Modules are just an implementation
that is intended to provide ease of extensbility.  The real question would
be: Is ease of extensibility fundamentally incompatible with security?