httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@gonzo.ben.algroup.co.uk>
Subject Re: setuid() again
Date Mon, 01 Jan 1996 15:40:44 GMT
> 
> > > I've explored the following suggestions:
> > > 
> > > * setuid to the user of the CGI script
> > > 
> > >    This method creates many support headaches.
> > > 	. users not understanding how to setuid a script
> > > 	. perl not wanting to exec a setuid script
> > > 	. ease of creating a wrapper for every user's CGI script
> > > 
> > > * cgiwrapper
> > > 
> > >    Disables the ability to have index.cgi
> > 
> > So fix it.
> 
> 'cgiwrapper' is not really designed with this in mind. My 'fix'
> is what I propose.

OK, lets go over the problem a step at a time. Why/how does it disable this
ability?

> 
> 
> > >    Some support issues with explaining it's use.
> > 
> > And integrate its use tightly into Apache.
> 
> Which is what the seteuid() stuff does.

At considerable extra danger.

> 
> 
> > > This brings me back to the use of seteuid() in the server.
> > > 
> > > While I agree that it is somewhat scary to be switching uids
> > > in our CGI code, there are benefits to this approach that 
> > > *improve* security as well. Correct me if I'm wrong...
> > > (as if I need to ask)
> > > 
> > > Most changes can be restricted to can_exec().
> > > 
> > > We can:
> > > 	disallow execution of any CGI by uid 0.
> > 
> > You should disallow all serving of anything by uid 0.
> 
> Which is done.

It is? How?

> 
> > > 	force the CGI script to be under the owners home directory
> > 
> > OK, but why? If they want to run a script outside their home dir, they just
> > write a script in their home dir saying:
> > /some/where/else/script
> 
> The solution would probably be to run in a chroot()ed environment.

Hmmm - then you have to copy all the utilities they might use into local
directories. As well as shared libraries, device files, etc.

> 
> 
> > > 	restrict system resources on OSs with setrlimit
> > 
> > And what of those without setrlimit?
> 
> You lose.
> 
> 
> > > It seems that after all of these conditions have been met,
> > > seteuid() to the owner of the script is relatively safe.
> > 
> > Ahem.
> > 
> > Apart from the danger of processing the request as root, and the objections
> > above, totally safe.
> 
> You are not processing the request as root. The server does a seteuid(0),
> immediately followed by a seteuid("owner of script"), processes the request
> as the owner of the script, and  then returns to being "nobody" or whomever
> you have chosen to run as.

Hmmm - stricly Apache should run in a mode where seteuid(0) doesn't work.

> 
> If we are really concerned about the security of Apache, then we should
> be doing more than a seteuid() to user_id in http_main.c.

Possibly so.

> 
> I am more confident in the security of Apache than sendmail. I still
> run sendmail. Have the rest of you disabled root daemons on your systems?

Well, I don't run sendmail.

Cheers,

Ben.

-- 
Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant        Fax:   +44 (181) 994 6472
and Technical Director      Email: ben@algroup.co.uk
A.L. Digital Ltd,           URL: http://www.algroup.co.uk
London, England.

Mime
View raw message