httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: suexec concerns
Date Sat, 04 Jan 1997 01:28:47 GMT
On Fri, 3 Jan 1997, Jason A. Dour wrote:

> Many of the issues being raised are based upon poor administration; we can
> never keep people from using something improperly...we can only document
> how to use it properly.  Not having shells and whatnot in webspace is a
> well-known problem...one that we can't fix.

Yes; I don't really care too much about that.  If someone puts a shell in
something that really is webspace, that's their problem (well.. only
sortof.  Consider the person that wants to distribute executables from
their web server, it is perfectly reasonable to put the file in a web
directory with the executable bit as long as it isn't seen as a CGI by the
server; I'm starting to think more and more that suexec needs to know what
is cgi space, not just what is web space).  If we make suexec know what is
webspace, it can deny anything that shouldn't be called as a CGI. 
However, it would take some careful looking to see if that could be done
without getting bloated.

> 
> As far as tightening down ~userdir requests, I think we need to get a way
> for the wrapper to verify its parent as an httpd process.  That would
> solve a good number of the issues presented.

Yes.  However, I'm not sure if that is possible on all platforms.  I am
fairly sure that there are some platforms where you can attach a debugger
to a process that is running under your id even though it started as root
and did a setuid.  Can't think of any examples I know for sure right now.
If you can attach to the process with a debugger, I have no confidence in
whatever you do to authenticate the suexec parent as a httpd process.  

Debuggers are just one of the things that can cause problems; there are
several other things which can have a similar impact.

If you have no way to get access to the innards of a process which is
running as your uid but which has done a setuid, you can close many of the
holes.

Hang on.  The parent httpd, normally running as root, knows for sure who
its children are.  All we need is a way for suexec to ask the parent if
process x is a child of the parent or not.  Part of that could be already
implemented in the scoreboard stuff.  Comments? 

> 
> On Fri, 3 Jan 1997, Randy Terbush wrote:
> > * tack user-cgi directory onto the ~user path.
> 
> 	-1.  I *still* think we need to find a solution that does not
> pre-compile the location.  If we don't we'll break SSIs even more than we
> have already...and what of Dir/Loc/File?  I think we should push this to
> 2.0.

I think we need a solution that doesn't hardcode it, but if we don't have
one before 1.2 we NEED to force requests to the user's web space.  Heck,
even forcing them to ~user/public_html would work.  The security holes if
this isn't done are just too gaping.

[...]
> 	We need to move carefully on some of these issues...  I don't want
> what is -- at present -- a decently functional suEXEC to become munged
> pre-1.2 roll-out due to new "features."  If its more than a bugfix, I vote
> for 2.0.

Agreed.  However, remember that although it is functional right now it has
security holes big enough to drive a whole flock of netscape servers
through... and that's pretty big.

If we can't fix them before 1.2, pull it from the 1.2 release and release
it separately after 1.2.


Mime
View raw message