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

[Joshua Brindle]

pageexec@××××××××.hu wrote:
> On 26 Apr 2006 at 10:58, Joshua Brindle wrote:
>
>> I don't agree that specific attack vectors are required to determine
>> whether a model is broken.
>>
>
> specific examples of attack are needed for people with less specialized
> knowledge in security (i might say, sometimes even for the specialists)
> but with the ability to understand a demonstration. sometimes the attacks
> one thinks of as 'breaking the model' are actually the result of the
> misunderstanding of the model.
>
>
That is silly. The model is to essentially sandbox apps. The problem is 
that the sandbox is leaky due to the abstractions being used (eg., 
paths). There is no way to determine that the policy you wrote is 
actually being enforced, and again, escalating privileges and increasing 
the potential for misuse.
>> The reasons I think the model is broken are pretty clearly laid out in
>> the url's posted.
>>
>
> there's not a *single* word about system calls in those posts. second,
> those 'pretty clear' reasons are anything but, i'll get to that on the
> blog itself though.
>
>
once again, model != implementation. I was talking about the model, and 
these particular posts weren't targeting systrace at all, as far as I 
knew this crap was off the radar.
>> 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.
>>
>
> my feeling is that you're looking at the whole world with a rather limited
> view, everything that doesn't fit the selinux view (as that's what this is
>
no.
> all about, isn't it) must necessarily be wrong. maybe before you do that,
> you should ask the authors about their threat model, use cases, etc and
> then evaluate their solution. fwiw, selinux is just as broken as anything
> else out there, down to the fundamental design level, and it's even more
> dangerous than other systems (gives false sense of security) as pretty much
> everyone sells it as The Solution for security. nothing could be further
> from the truth, so let's not look down on others just because they don't
> fit your particular (mis)understanding of security.
>
>
That is absolutely false. If some person sells selinux as The Solution 
that is one thing, I have never said and will never say that SELinux is 
any kind of end all for security.

The false sense of security is also a lie. Unlike path based systems the 
SELinux policy can be analyzed and precise (and non-ambiguous) access 
vectors can be observed and removed if necessary. Further, you are 
confusing the policy with the mechanism. The mechanism is not 
fundamentally flawed at the design level (you didn't mention any design 
flaws, and I don't know of any, speak up if there are)

The fact is on _ANY_ path based system you cannot tell if the policy you 
wrote (and are running) is actually being enforced by the system because 
of ambiguity of filenames. That is not the case with SELinux. Some group 
of people blindly trusting the policy we give them is one thing but you 
are attacking the very mechanism which is total bullshit.
>> "If I don't push yes this won't work", these systems have been shown
>> time and time again to fail.
>>
>
> any specific examples?
>
> and my quiz of the day: how's blindly turning audit2allow into a policy
> better than blindly clicking yes on a messagebox? it's not yet that's
>
And have I ever suggested this? This is not about what someone on 
#selinux says, this isn't about what Red Hat says (even though they 
don't advocate doing that blindly). The system can be abused, no shit. 
Giving users the opportunity to abuse it easier is not a good thing.
> exactly what some suggest as a fix for selinux denials. look here for
> an example: http://www.linuxsecurity.com/content/view/120837/49/ and
>
I don't care what some random person says is the way to write policy. 
That is NOT what we advocate and that is irrelavent to the discussion 
(or we could start talking about how horrible learning mode is, your 
choice..)
> you can google for more. i'm not saying that user interaction is a good
> or bad idea, but i am saying that this cannot be the reason for objecting
> against systrace as it applies to selinux as well.
>
>
Who cares? I can write 500 pages about blindly using learning mode to 
write "least privilege" pages, that doesn't make it right or 
representative of the developer community for that particular system. 
Try again.
>> 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.
>>
>
> maybe you should give examples here as well, so that the systrace people
> can elaborate.
>
>
umm, its pretty obvious, want a picture? here:

SELinux:
attacker --> kernel DAC/capability checks --> selinux access checks --> 
capabilities granted.
systrace:
attacker --> systrace --> capabilities granted.

>>> 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.
>>
>
> you have specifically mentioned apparmor and grsec, and not exactly with
> flattering words (not that i expected something else from you but still,
> what's with the link to the '6 dumbest ideas' rant by Ranum, which fwiw,
> has also been rebuked on the dailydave list?).
>
Sorry, apparmor isn't even in the same class as grsec in terms of the 
security it provides, I probably shouldn't have coupled them like that :)

> as a reminder, you kicked off with the following:
>
>> An Anti-Pattern is a commonly reinvented bad solution to a problem. In
>> security there are lots of these, The Six Dumbest Ideas in Computer
>> Security outlines several that are fairly common but I’m going to go
>> into detail about one in particular that several semi-popular security
>> mechanisms adopt.
>>
umm, "rebuked".. if you want to call it that, claiming that "hacking is 
cool" is hardly compelling. The ideas on that page are good pointers in 
general for security systems, I never saw anything claiming the actual 
points were inaccurate *shrug*
>
> if that's not an invitation for a flamewar, then i don't know what is.
> but then, you asked for it, we'll see how smart you(r) selinux folks are.
>
I have no desire to get into a flameware (or the energy/time). 
Professionally grsec, apparmor, systrace are irrelavent, the people I 
deal with need analyzable policies and labeled objects (you can make fun 
of CC requirements all you want but it doesn't matter in the least bit).

Personally I'd like to help security in general. Fedora has SELinux 
enabled by default and protects several daemons by default. This is 
clearly a win for security, MAC in a general use OS is unheard of, we 
are breaking new ground here.

Incase you forgot hardened *does* support grsec, RSBAC and SELinux. 
grsec is in no way a second class citizen, when people come to the 
channel with problems I try to help them, I don't tell them they are 
stupid and need to switch to SELinux. I even suggest that people who 
have very lightweight security needs use grsecurity. In practice (eg., 
normal systems, normal people, etc) grsec can be very effective. My blog 
posts are about security philosophy (as i stated in the first post) and 
best practices. As you, and I know security is 100% about tradeoffs. 
Sometimes the more secure solution is not the best for the situation.

I'm not sure what "you asked for it, we'll see how smart you(r) selinux 
folks are" is suppose to mean, is that a threat? Are you going to make 
fun of us on blogs and mailing lists?


-- 
gentoo-security@g.o mailing list