[E-Lang] defense in depth

Ben Laurie ben@algroup.co.uk
Sun, 28 Jan 2001 23:27:10 +0000


"Jonathan S. Shapiro" wrote:
> 
> > I have to say that an Apache designed for a capability system would
> > probably be a very different beast from the Apache we have today. But
> > there are things capabilities can do as a bolt-on that are still vastly
> > superior to what we can do today without making huge changes to Apache.
> > CGI confinement being the easiest example to explain and think about.
> 
> It would be quite useful if you could enumerate some of them.

I've been thinking about this, and the funny thing is that where I keep
coming back to is that CGIs, instead of being the most dangerous thing
in Apache, suddenly become one of the safest. That is, because they are
the _only_ part of Apache that is currently run as a separate process,
they lend themselves to confinement. So, where I keep ending up is that
in a largely unmodified Apache, you actually want to serve all content
via CGIs, but be rather careful about what capabilities those CGIs have
access to.

That, however, is really a technical detail. The question is what could
be better handled with capabilities in Apache. So, here's a short list:

a) Access control. Currently a URL, directory or file can have access
controlled by a user/password list. Two obvious enhancements to this
exist: 1) control by distributed capabilities - this would require
modifying HTTP some, though and 2) tying user IDs to capabilities
(shudder: ACLs anyone?), which inverts the model, but radically reduces
the opportunity for cockup (note that there would probably have to be an
anonymous user to tie capabilities for uncontrolled URLs to).

b) "suexec" - there's an optional facility in Apache to run CGIs as
other users, usually depending on the location of the CGI. This is
fraught with danger in the standard environment (which is why it it is
disabled by default), because we have no sure way to prevent things
_other_ than the webserver from invoking it. I believe capabilities can
be used to completely eliminate that danger (in the final analysis, the
ability would be to use certain capabilities, rather than "run as
another user", of course).

c) symlinks - there are options to follow or not follow symlinks,
possibly factoring in the owner of the symlink. I'm not sure how
capabilities apply to this, but I have a feeling they do. The ability to
follow them is often a security risk.

d) The URL space - Apache allows you to define things in terms of URLs,
files or directories, including permissions (to access or not to access,
to execute or not to execute and so on) - and then maps URLs onto
directories in a more-or-less independent way. It is scarily easy to
screw up and accidentally allow access to things you shouldn't have, or
execution in directories you shouldn't have. I feel sure that even a
simple-minded application of capabilities to these matters would
considerably reduce the margin for cockup.

That'll do for starters.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff