Re: [gentoo-security] Re: [gentoo-hardened] Systrace resurrection

[Andrea Barisani <lcars@gentoo.org>]

On Wed, Apr 26, 2006 at 12:59:03PM -0400, Joshua Brindle wrote:
> 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.

Did you bother checking how systrace checks/applies the path? (the tone isn't
accusatory here, I didn't do it yet myself, but still we can't flame it without 
knowing its implementation, this is not as easy to evaluate as you try to put 
it design-wise). Admitedly you don't know much about systrace implementation, 
would you kindly check into it and see how it *really* works before judging it? 
Not saying that this should make you change your mind but it would probably be 
best and it would allow a much more constructive feedback.

Neils, any comments about this?

> What you are doing in essence is making all binaries setuid by allowing 
> privilege escalation. Think about it, setuid tells the linux kernel to 

"all binaries" ? I never said that I'd apply this to all binaries, systrace
is discretionary so to speak...

> 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.
> 

systrace "becomes" a kernel feature, systrace "bypassing" the kernel makes no 
sense to me, but I guess this is a semantic issue...

This is just moving the all-permissive setuid concept (which I might say can be 
arguably a kinda broken/insecure thing) to a syscall acl framework.

> 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.
> 

Systrace can lower the security level of the system if *you* configure it to
do so as *root* (which could do that anyway), this is just shifting the sec
model from 'setuid lets the process run as root but we "jail" it with MAC' to
"we remove setuid and we selectively allow kernel_side what it can do".

Unless you are really dumb in defining policies I can't see how this could be
heavily mis-used / compromised.

Neils, Method: all feedback is welcome.

Cheers

-- 
Andrea Barisani <lcars@gentoo.org>                            .*.
Gentoo Linux Infrastructure Developer                          V
                                                             (   )
PGP-Key 0x864C9B9E http://dev.gentoo.org/~lcars/pubkey.asc   (   )
    0A76 074A 02CD E989 CE7F AC3F DA47 578E 864C 9B9E        ^^_^^
      "Pluralitas non est ponenda sine necessitate"
-- 
gentoo-hardened@gentoo.org mailing list