httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From KaiGai Kohei <kai...@ak.jp.nec.com>
Subject Re: [RFC] A new hook: invoke_handler and web-application security
Date Thu, 09 Apr 2009 02:26:56 GMT
Joe Orton wrote:
> On Wed, Apr 08, 2009 at 09:09:14AM +0100, Nick Kew wrote:
>> On 8 Apr 2009, at 08:32, Joe Orton wrote:
>>
>>> So I'm not sure that it's worthwhile.  Having said that, it seems a 
>>> lot more worthwhile than the mod_privileges approach in the trunk, 
>>> which seems to claim it is secure so long as you don't execute 
>>> untrusted code, so I'm not sure what threat model that addresses at 
>>> all.
>> That's untrusted, privileges-aware code.
> 
> "This stab-proof vest protects you from being stabbed by all attackers 
> who are not holding a knife"
> 
>> Use case: mod_php, whose safe_mode prevents loading such code.
> 
> safe_mode is security theatre, it's not a reliable sandboxing mechanism, 
> and is being removed in PHP6, thank goodness.  The point is: if you are 
> interpreting PHP code in-process, from a security standpoint you must 
> consider it equivalent to running arbitrary executable code.  Arbitrary 
> executable code can, so far as I can tell, revert whatever changes 
> mod_privileges made to the process' privileges - is that not correct?

I'm not good at Solaris.
However, SElinux does not allow to revert its privilege (security context)
unconditionally, even if it is dynamically changed.
If we want to revert it, the security policy has to allow B->A in addition
to A->B, but it is generally nonsense.
It is also the reason why we need a one-time thread or process to assign
individual privileges for each requests.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

Mime
View raw message