httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Terbush <>
Subject Re: Question for the development team
Date Sun, 17 Aug 1997 17:16:03 GMT
> On Wed, 13 Aug 1997, Randy Terbush wrote:
> >
> > suEXEC currently doesn't do a chroot() for CGI execution. There are 
> > several reasons that we did not take this extra step.
> > 
> > 1. chroot() environments are not easy to setup
>     No, and what's worse is that getting it right is different for
> every flavour of UNIX.  Having said that, anyone who has set up a
> typical anonymous FTP service will have most (if not all) of a working
> chroot environment.  I'd hate to see useful functionality left out of
> Apache because we think most people will fumble around cluelessly if
> they try to use it.  Put big warnings around it or something.

Running Apache chroot'ed doesn't really require source changes. The 
user-level 'chroot' command accomplishes this nicely.

> > 2. CGI often wants access to other tools outside of the local
> >    directory which would make it rather difficult to setup.
>     True, but again it is up to the admin to correctly configure the
> environment, and not Apache's place to limit what the admin wants to
> do.  I'd rather take my chances on having a CGI break in a chroot jail
> than not having the chance at all.

On the contrary. Apache has not limited that at all. The suEXEC 
API, (such that it is) is very extensible. Adding chroot() into the 
existing wrapper is probably a one line change.

> > 3. suEXEC already limits execution of CGI to a compiled in 
> >    DOCUMENTROOT which offers _some_ of the benefit of a chroot() 
> >    without the hassle.
>     I can't change DOCUMENTROOT on a per virtual server basis, which
> makes it useless in my situation.  My situation:  customers currently
> have chrooted FTP (with login/paassword) and qpopper access to our
> hosting servers.  All services they can use (HTTP, FTP, POP3) are
> chrooted to their home directory.  I don't want to break this policy
> for those who want CGI's.


>     In any case, a suexec'd CGI still has visibility of the entire
> filesystem (including the directories of other virtual domains), and
> can write to areas like /tmp.

Agreed, which is desireable in most installations. suEXEC offers 
significant improvements in CGI security when configured as is. In 
a more hostile environment which you are apparently dealing with, I 
can understand a desire to limit this. However, why not just run 
the entire server chroot'ed?

> > 4. suEXEC runs the CGI as the defined owner of the file. *In 
> >    Theory* the CGI being executed can only do as much damage as 
> >    that user has privledges to do.
>     ... and we all know how many recent root exploits have been
> recently reported possible with an unprivileged account.  :(  You
> might as well give CGI users a shell account on your system.
> > It is all a matter of degree of risk. In a more hostile environment,
> > it may very well be worth making the changes to run in a chroot'ed
> > environment.
>     Is anyone considering putting in chroot() functionality into
> suexec?  Alternatively, are there other existing wrappers that can
> perform the same function?  I like all the other checks suexec
> performs though.  If it could chroot() before running the CGI, it
> would be perfect.

As I mentioned above, it is probably a trivial change which could 
be offered as a compile time option. However, given the amount of 
mail that we have seen from people having problems with the 
standard functionality, I would question the benefit of 
complicating suEXEC further to accomplish something that IMO is 
more completely accomplished by running the server chroot'ed.

I'm sure that we would consider patches to suexec that would add 
chroot() capability as a compile option if you have them.


View raw message