[5022] in WWW Security List Archive
Re: Security issues in Apache?
daemon@ATHENA.MIT.EDU (Steff Watkins)
Thu Apr 10 15:08:44 1997
Date: Wed, 9 Apr 1997 09:44:54 +0100 (BST)
From: Steff Watkins <Steff.Watkins@Bristol.ac.uk>
To: www-security@ns2.rutgers.edu
In-Reply-To: <334A53D3.5A04@nationwide.com>
Errors-To: owner-www-security@ns2.rutgers.edu
On Tue, 8 Apr 1997, Steve Neruda wrote:
> Christopher Petrilli wrote:
>
> > If you're running it, I would recommend you run an absolute minimal
> > server on port 80, an run the rest on a totally untrusted port, like
> > 8080, thereby elimanting the need to even start the server as root. This
> > would at least restrict the damage that could be done.
> >
>
> Since the server relinquishes root as soon as it's bound to the port is
> this added complexity really necessary?
Full agreement with Steve here.. The ORIGINAL instance ("parent process") of
the webserver that is run must be by 'root' if you are planning on
having your webserver answer calls on port 80 as root is the only user
that can bind processes to ports less than 1024.
However, once it has received a call, it spawns off an instance ("child
process") of itself to reply to that call. This instance will assume the
userid that you state for the webserver in the config files (UserId in
httpd.conf for NCSA, for example).
As such, the webserver ANSWERING the call could be (should be) 'nobody',
and running with 'nogroup' privs. That way, if your webserver does go
ass-up, then there is little damage that can be done to your system.
> If someone finds a buffer overflow and gets a shell then it will be
> under the uid the server is *currently* running as, not root.
Agreed. But, this has nothing to do with the user who STARTS the
webserver up from the OS level. It all depends on the userid the webserver
has been told to assume.
> > Again, this is all principle. The basic theory is that if you can't
> > PROVE it's trustable, then it isn't. Don't trust ANYTHING.
It comes down to 'levels of acceptable risk'. What I mean is, that if you
can handle a security breach, then do it.. if you can't, then don't!
Within my domain, a lot of the systems are used for undergraduate teaching.
The majority of the contents are emails and type-ups of course notes.
Daily backups are performed. If there was a security breach, then the
most that could be lost would be a week-end's worth of filechanges.
Nothing too potentially devastating. We run webservers on these systems.
However, people who have 'valuable' data (relating to their business or
research) should consider the risks of using a webserver on their main
system.
Simple as that really..
Steff
