Re: [gentoo-hardened] Systrace resurrection

[Joshua Brindle <method@gentoo.org>]

Andrea Barisani wrote:
> I re-read your blog entries and I still fail to see how's systrace affected
> by this. So just assume that I'm Dumb (tm) and please show me a
> implementation-specific example of this, also consider that systrace is *not*
> a MAC and it doesn't want to be one, we are systracing processes explicitely
> here.
>
>   
Well, systrace is path based so you can apply all those arguments 
directly. I don't understand what you mean by systrace is not MAC, what 
is it? It has a policy, it enforces access control. I guess choosing to 
run the app under it directly makes it discretionary. It still has all 
the issues that my blog such as ambiguous paths, problems in shared 
directories, etc.
>> "If I don't push yes this won't work", these systems have been shown 
>> time and time again to fail. And, like I already said, bypassing 
>> in-kernel DAC and capability restrictions means that there is now a 
>> single attack vector to gain all system privileges. This means systrace 
>> actually *removes* a layer of security from the system, which is clearly 
>> a bad idea.
>>     
>
> It can only if you don't know how to configure/use it, which is something
> that applies to SELinux, grsecurity, RSBAC and every other system. Feel free
> to prove me wrong here with examples ;).
>   
What you are doing in essence is making all binaries setuid by allowing 
privilege escalation. Think about it, setuid tells the linux kernel to 
change the uid when this app is run, so you "remove" the setuid bit and 
let systrace escalate the capabilities by bypassing the kernel, this is 
not different from just having the binary be setuid and then only 
allowing whichever caps it needs and is more dangerous since there is a 
single layer controlling capabilities for an attack vector.

Neither grsecurity nor SELinux allow any kind of bypass of standard 
linux kernel permissions. They cannot lower the security level of the 
system whereas systrace can by granting capabilities that processes 
would not have had otherwise.

>>>> http://securityblog.org/brindle/2006/03/25/security-anti-pattern-status-quo-encapsulation/
>>>> http://securityblog.org/brindle/2006/04/19/security-anti-pattern-path-based-access-control/
>>>>    
>>>>         
>> On the blog is fine. Remember that those posts aren't targeting specific 
>> implementations (eg., grsec is not affected by all of the issues listed) 
>> but rather the model in general.
>>     
>
> I'm curious, why's grsec not affecteced by this?
>   
grsec's access control is affected by many of them. Most grsec users 
don't use the access control, however, they use the other protections 
(the 80% attack vector thing..)
-- 
gentoo-hardened@gentoo.org mailing list