httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: PID table changes (was Re: svn commit: r547987 - in /httpd/httpd/trunk)
Date Thu, 21 Jun 2007 22:20:07 GMT
Joe Orton wrote:
> On Thu, Jun 21, 2007 at 06:18:59PM +0100, Colm MacCarthaigh wrote:
>> On Thu, Jun 21, 2007 at 05:51:34PM +0100, Joe Orton wrote:
>>> On Sat, Jun 16, 2007 at 09:29:25PM -0000, Jim Jagielski wrote:
>>> Secondly: I think this approach is unnecessarily complex.  I think it's 
>>> sufficient to simply check whether the target process is in the right 
>>> process group before sending a signal, i.e. getpgid(pid) == getpgrp().  
>>> This ensures that the parent will only kill things it created.
>> I actually thought avoiding this was a design goal, to prevent someone
>> from killing piped loggers and cgi processes ? 
> 
> What's the security threat there?  Given that the attacker can arrange 
> for arbitrary execution of code in any unprivileged child, preventing 
> logging or CGI script execution is possible anyway.

Two different cases.  It will be trivial to kill the CGI scripts launched
from the process (not from cgid) for other children in, say, a worker
config.  The cgid and logging processes spawned by the parents aren't
vulnerable as such (and the logging processes are spawned with the httpd's
launching uid anyways, not nobody, IIRC.)

We only care about constraining the fallout of a malicious in process
script to that specific process, and the loggers, if we go beyond testing
the pid group, won't have that issue from the child process.

So I agree with testing the pid groups, I also believe it is worthwhile
to sanity test any critical data from the shared-scoreboard against the
parent processes' private reference table.

Mime
View raw message