Re: BOA was: An issue with Apache on Debian

[boa () CRYNWR COM (boa () CRYNWR COM)]

I know I don't have the same credentials as some of the net.gods
that post here, but as a maintainer of the web server Boa, and a
generally active *nix user/programmer/admin who cares about
security, I'd like to weigh in on the subject of web server setup
and more general issues of computer security technique.  I hope
this essay doesn't come across as too pedestrian or long-winded.

There is certainly some value in not leaking machine configuration
onto the net at large.  In a perfect world, it wouldn't matter,
but people and their software are not perfect [1].

OTOH, you would rightly ignore an assertion that zyxmail was
insecure, because any user on the system can use it to send a
copy of /etc/passwd to alt.2600.  Hey, you're the one who gave
the luser an account, you can yank it too.  Why, then, should
one be concerned that a user can "ln -s / $HOME/public_html"?

I know Apache can be configured to not follow symbolic links from
user directories [2].   Many other programs, Boa included, don't
attempt to recreate or second guess the protection mechanisms built
into the OS they run under.  This is a personal beef I have with
people who ask for, and programmers that provide, bloated programs.

Daemons run with the uid/gid selected by the sysadmin [3],
typically an "unprivileged user" [4].  The nominal expectation
should be that remote users of a such a daemon can make it take
any action on their behalf, limited by the permissions of that
uid/gid.  This is certainly true of Boa when semi-untrusted users
are given control over part of the web virtual space, such as
with the usual $HOME/public_html mechanism.  It is also true of
any daemon that has an exploitable buffer overflow bug; containing
such attacks is a big motivation for using an untrusted uid in the
first place.

My recommendation: if you have semi-untrusted users on your system,
and you consider some configuration files sufficiently sensitive
that you don't want them splattered all over the internet, don't
protect them 755 [5].

There are times when a webserver should show a different virtual
spaces depending on from where the request comes in -- e.g., local,
intranet, or big bad world [6].  I suspect this concept has to make
it into the Debian web policy, in particular to show /doc to local
users, but not the outside world.  Of course, Apache can do that.
With minor tweaks or hacks, most other web servers can too [7].

I have learned that the *nix security model, while less than perfect,
is far more adaptable and flexible than most people give it credit
for.  Don't ignore it or fight it, use it to your advantage.

    - Larry Doolittle  <ldoolitt () boa org>


[1] It is actually quite reassuring that we have the time to
worry about subtle information leakage.  It doesn't seem like
too long ago that bugtraq was full of instant remote root exploits.

[2] Of course, to implement this, Apache stat()'s every
component of the path on every request.

[3] Or system integrator.  People who put a Red Hat or other
preconfigured system live on the 'net without investigating
what's really there are fools.

[4] Historically nobody/nogroup.  This is arguably overused.
A more modern setup allocates a specific uid/gid for each task.

[5]  I personally get frustrated trying to make such a machine
work (in a mortal user role), because I can't self-diagnose
problems.  I found a "final solution" to this problem many years
ago, now I have root privileges on my own machine.

[6] Based on IP number, not name, of course.  DNS is too slow
for me, and raises security questions of its own.

[7] I haven't checked how easy it is with the features of the Debian
version of Boa.  If someone tells me it's needed and will be used,
_and_ gives a useful description of how to configure it, I can
certainly program it.  Test and internal use copies of Boa have
already implemented features along this line.