[gentoo-hardened] Systrace resurrection

[gentoo-hardened] Systrace resurrection

[Andrea Barisani]

Hi folks!

I'd like to announce that Systrace is back in the portage tree, it consists
of two packages:

sys-apps/systrace

the userspace application that now features a ptrace backend in case the
kernel patch is not installed.

sys-kernel/systrace-sources

this is standard kernel with our base patchset + systrace patch.

We are trying to get this in hardened-sources as well, as I said you don't
need the kernel patch to try this out, granted that the ptrace backend is
much slower and really useful only for testing/debugging purposes, in the
long run the patch is the way to go.

Testing/feedback is appreciated.

More information here:

http://www.systrace.org
http://www.citi.umich.edu/u/provos/systrace/

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

Re: [gentoo-hardened] Systrace resurrection

[Joshua Brindle]

Andrea Barisani wrote:
> Hi folks!
>
> I'd like to announce that Systrace is back in the portage tree, it consists
> of two packages:
>
> sys-apps/systrace
>
>   
No, remove it.
> the userspace application that now features a ptrace backend in case the
> kernel patch is not installed.
>
> sys-kernel/systrace-sources
>
> this is standard kernel with our base patchset + systrace patch.
>
> We are trying to get this in hardened-sources as well, as I said you don't
> need the kernel patch to try this out, granted that the ptrace backend is
> much slower and really useful only for testing/debugging purposes, in the
> long run the patch is the way to go.
>
>   
Absolutely not.
> Testing/feedback is appreciated.
>
>   

Systrace has a broken security model which allows, among other things, 
privilege escalation. It is our (hardened) opinion that it is harmful to 
security and the cause of hardened. I ask you to remove it. If you don't 
we cannot and will not support it, and will discourage its use among our 
users.
-- 
gentoo-hardened@gentoo.org mailing list

Re: [gentoo-hardened] Systrace resurrection

[Andrea Barisani]

On Wed, Apr 26, 2006 at 09:38:02AM -0400, Joshua Brindle wrote:
> Andrea Barisani wrote:
> >Hi folks!
> >
> >I'd like to announce that Systrace is back in the portage tree, it consists
> >of two packages:
> >
> >sys-apps/systrace
> >
> >  
> No, remove it.
> >the userspace application that now features a ptrace backend in case the
> >kernel patch is not installed.
> >
> >sys-kernel/systrace-sources
> >
> >this is standard kernel with our base patchset + systrace patch.
> >
> >We are trying to get this in hardened-sources as well, as I said you don't
> >need the kernel patch to try this out, granted that the ptrace backend is
> >much slower and really useful only for testing/debugging purposes, in the
> >long run the patch is the way to go.
> >
> >  
> Absolutely not.
> >Testing/feedback is appreciated.
> >
> >  
> 
> Systrace has a broken security model which allows, among other things, 
> privilege escalation. It is our (hardened) opinion that it is harmful to 
> security and the cause of hardened. I ask you to remove it. If you don't 
> we cannot and will not support it, and will discourage its use among our 
> users.
> -- 
> gentoo-hardened@gentoo.org mailing list
>

*sigh*

I thought that this flamewar was dead. Ok, I kindly ask a hardened team
review of this since I strongly believe this is not an issue, systrace is
*not* a broken security model and yes it allows *controlled* privilege
escalation if you configure it that way for removing the setuid but on some
binaries.

If you have an argument to make please show me the technical details about it
and let's discuss it.

It's *not* part of hardened atm anyway and it won't be unless the hardened
team accepts it. It will remain in the portage tree as long as I support it
unless you show me a clear demonstration of your concerns.

BTW even with your concern the ptrace method (which can be entirely tested
userspace) is still useful for debugging/testing, hence the userspace package
has no reason for going away.

CC'ing systrace author btw (not subscribed to this list).

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

Re: [gentoo-hardened] Systrace resurrection

[Joshua Brindle]

Andrea Barisani wrote:
> <snip>
>
> *sigh*
>
> I thought that this flamewar was dead. Ok, I kindly ask a hardened team
> review of this since I strongly believe this is not an issue, systrace is
> *not* a broken security model and yes it allows *controlled* privilege
> escalation if you configure it that way for removing the setuid but on some
> binaries.
>   
This is no flamewar. The model is broken by my standards. It bypasses 
built-in DAC and capabilities in the kernel making it the single attack 
vector to gain all access on the system. Compare to grsecurity, rsbac, 
selinux which do not bypass kernel access control or escalate privileges.

Further, the "lets ask the user if they want to allow this" is 
inherently flawed. It is a discretionary model, the policy is in no way 
analyzable. I suggest you read these articles:
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/

> If you have an argument to make please show me the technical details about it
> and let's discuss it.
>
> It's *not* part of hardened atm anyway and it won't be unless the hardened
> team accepts it. It will remain in the portage tree as long as I support it
> unless you show me a clear demonstration of your concerns.
>   
First it will never be accepted by hardened. Second, I believe that 
security critical packages (particularly access control systems) should 
go through hardened. Random developers *should not* be putting access 
control mechanisms in the tree, users will have security expectations 
that they cannot meet.
> BTW even with your concern the ptrace method (which can be entirely tested
> userspace) is still useful for debugging/testing, hence the userspace package
> has no reason for going away.
>   
As long as its clearly marked as a debugging tool and not as a security 
tool.
> CC'ing systrace author btw (not subscribed to this list)

Great.
-- 
gentoo-hardened@gentoo.org mailing list

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

[Andrea Barisani]

On Wed, Apr 26, 2006 at 10:01:54AM -0400, Joshua Brindle wrote:

> This is no flamewar. The model is broken by my standards. It bypasses 
> built-in DAC and capabilities in the kernel making it the single attack 
> vector to gain all access on the system. Compare to grsecurity, rsbac, 
> selinux which do not bypass kernel access control or escalate privileges.
> 
> Further, the "lets ask the user if they want to allow this" is 
> inherently flawed. It is a discretionary model, the policy is in no way 
> analyzable. I suggest you read these articles:
> 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/
> 

Thanks for the links.

It appears we have different standards. I don't find it "broken" at all while
I still see why it's not compatible with yours standards. I can see the
design issue maybe, but that's far from considering it "broken" or a security
issue imho.

This is just a matter of perspective. And anyway one thing are design issues,
one is a real security problem. As it is now sys-apps/systrace and/or
sys-kernel/systrace are not a security issue from a
vulnerability/exploitability POV. So I'm going to keep it there as a
standalone thing, regarding Hardened inclusion we'll discuss this (since I'd
like to hear other hardened team opinions) and if the team doesn't agree then
fine it won't be supported.

> First it will never be accepted by hardened. Second, I believe that 
> security critical packages (particularly access control systems) should 
> go through hardened. Random developers *should not* be putting access 

I completely disagree with this, security critical packages should not go
through hardened by default and anyway there is no policy for that. This case 
is an example of why the policy is broken. I want to provide the *choice* of 
using/installing systrace, if this doesn't appeal your standards it doesn't necessarily 
mean it should be removed from the tree (unless it's a security issue, which is clearly 
not).

Btw we are not advertising/documenting this as the perfect security solution, 
so let's not make a big fuss about a unstable ebuild. This *random* developer
(member of the Gentoo Security team) would just like to provide a choice to
our users.

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

Re: [gentoo-hardened] Systrace resurrection

[pageexec]

On 26 Apr 2006 at 10:01, Joshua Brindle wrote:
> This is no flamewar. The model is broken by my standards. It bypasses 
> built-in DAC and capabilities in the kernel making it the single attack 
> vector to gain all access on the system. Compare to grsecurity, rsbac, 
> selinux which do not bypass kernel access control or escalate privileges.

it'd help the discussion/review (which is what Andrea asked for) if
you/others were more precise and cited specific attacks. generic hand-
waving of 'this is broken' doesn't help it. this is not to say that
i disagree with your opinion (fwiw, you and spender are on the same
side for once ;-).

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

it's funny that you mention these as i just came across them and was
going to post a rebuttal to many of your claims. do you want them here
on the list or on the blog (it will probably take a few days until i
have enough free time though)?

-- 
gentoo-hardened@gentoo.org mailing list

Re: [gentoo-hardened] Systrace resurrection

[Joshua Brindle]

pageexec@freemail.hu wrote:
> On 26 Apr 2006 at 10:01, Joshua Brindle wrote:
>   
>> This is no flamewar. The model is broken by my standards. It bypasses 
>> built-in DAC and capabilities in the kernel making it the single attack 
>> vector to gain all access on the system. Compare to grsecurity, rsbac, 
>> selinux which do not bypass kernel access control or escalate privileges.
>>     
>
> it'd help the discussion/review (which is what Andrea asked for) if
> you/others were more precise and cited specific attacks. generic hand-
> waving of 'this is broken' doesn't help it. this is not to say that
> i disagree with your opinion (fwiw, you and spender are on the same
> side for once ;-).
>
>   
I don't agree that specific attack vectors are required to determine 
whether a model is broken. The reasons I think the model is broken are 
pretty clearly laid out in the url's posted. There are also others for 
this specific implementation. It is a dire problem to facilitate 
non-security aware/minded users to add rules to the policy dynamically. 
"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.
>> 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/
>>     
>
> it's funny that you mention these as i just came across them and was
> going to post a rebuttal to many of your claims. do you want them here
> on the list or on the blog (it will probably take a few days until i
> have enough free time though)?
>   
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.
-- 
gentoo-hardened@gentoo.org mailing list

Re: [gentoo-hardened] Systrace resurrection

[Andrea Barisani]

On Wed, Apr 26, 2006 at 10:58:17AM -0400, Joshua Brindle wrote:
> pageexec@freemail.hu wrote:
> >
> >it'd help the discussion/review (which is what Andrea asked for) if
> >you/others were more precise and cited specific attacks. generic hand-
> >waving of 'this is broken' doesn't help it. this is not to say that
> >i disagree with your opinion (fwiw, you and spender are on the same
> >side for once ;-).
> >
> >  

thanks :)

> I don't agree that specific attack vectors are required to determine 
> whether a model is broken. The reasons I think the model is broken are 
> pretty clearly laid out in the url's posted. There are also others for 
> this specific implementation. It is a dire problem to facilitate 
> non-security aware/minded users to add rules to the policy dynamically. 

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.

> "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 ;).

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

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

Re: [gentoo-hardened] Systrace resurrection

[Joshua Brindle]

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

Re: [gentoo-hardened] Systrace resurrection

[Joshua Brindle]

Niels Provos wrote:
> On 4/26/06, Joshua Brindle <method@gentoo.org> 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
>>     
>
> Let's take this opportunity to avoid misunderstandings.  I don't know
> very much about mandatory access control nor SELinux in particular.
> However, I certainly support the statement that Systrace is not a MAC
> system nor does it want to be one.  It would be great if you could
> help improve my understanding of SELinux by explaining the SELinux
> policy that governs, for example, your IRC client.
>   
That is fair. If noone involved considers systrace MAC then I'm less 
inclined to care about its availability, I'm still very concerned about 
privilege escalation and user interaction. I will not concede that this 
sort of activity (particularly the privilege escalation) is very dangerous.

SELinux is mandatory so the policy would already be loaded into the 
kernel. The irc client executable would be labeled (something like 
irc_exec_t). The user shell process would have a label (user_t) and 
user_t executing irc_exec_t would cause a transition into user_irc_t. 
The user_irc_t would then only have access to the resources it needs, 
network, its own files in your home and tmp. Derived domains like 
user_irc_t are used to seperate user apps from one another (without the 
assistance of DAC).

There are tons of resources about how selinux works policy-wise though. 
What in particular do you want to know?
-- 
gentoo-hardened@gentoo.org mailing list

Re: [gentoo-hardened] Systrace resurrection

[Andrea Barisani]

On Wed, Apr 26, 2006 at 02:54:15PM -0400, Joshua Brindle wrote:
> Niels Provos wrote:
>
> That is fair. If noone involved considers systrace MAC then I'm less 
> inclined to care about its availability, I'm still very concerned about 
> privilege escalation and user interaction. I will not concede that this 
> sort of activity (particularly the privilege escalation) is very dangerous.
>

Even if it's only allowed to root and/or systraced processes ? 

(let's remember that systrace is something that must be very selectively
enabled and that the privilege elevation thing is only available to root on
processes started with systrace)

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

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

[Andrea Barisani]

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