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

[Joshua Brindle]

pageexec@××××××××.hu wrote:
> On 26 Apr 2006 at 13:38, Joshua Brindle wrote:
>
>> 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.
>>
>
> is there any particular reason you're avoiding answering my (Andrea's,
> for that matter) requests for specific attack examples?
>
> it's my observation that you as well as many other selinux advocates
> often try to stay at some superficial theoretical level of 'attacks'
> as if that meant anything in the real world. it means nothing, so
> please try get down from that 'high horse' and answer the questions.
>
I do not believe that specifying a specific vulnerability is required 
for a model to be broken. I also do not actively try to break systems 
(penetrate and patch methodology) to decide if they are broken, any 
theoretical problem with the model is exploitable in the worst case 
scenario, that is enough. There is nothing 'high horse' about it, do you 
think people that build skyscrapers have to see the natural disasters 
that will destroy the buildings first hand? No, they have models for 
everything, the sky scraper itself, the possible 'attacks', etc.
> <snip>
>> 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.
>>
>
> what is it that you say about selinux then? clearly, you must have an
> opinion about its place in the world of security solutions. i.e., is
> there (according to you) a situation where say apparmor or grsecurity
> provide better security (you get to define what security means in that
> situation) than selinux? i'm all ears ;-). you realize that if you
> cannot provide such a situation then you'll have effectively confirmed
> my statement.
>
>
what best suits your needs depends on your security needs. I've always 
said this in hardened. I have no need to create imaginary situations, 
I've suggested to many people in #gentoo-hardened that grsecurity might 
meet their needs better than other solutions.
> <snip>
>
> you suggested that systrace should be rejected (among others) because
> it allows the user to (re)define the policy based on feedback from the
> access control mechanism. all i pointed out was that the same applies
> to selinux as well (and it does happen in real life too) yet you're
> not suggesting its removal. you can't have it both ways.
>
>
There is a huge difference between a policy loaded into the kernel that 
is mandatory at all times (and can be modified when necessary) and a 
policy that is in userspace, is entirely dynamic, and pops up with a 
dialog when a new access attempt happens. Clearly the policy has to 
change to the environment, however in general MAC policies should not be 
changing at run time. Since the systrace author has said that systrace 
is not and does not want to be MAC this might be a non-issue. Just as 
long as anyone using systrace knows they aren't using a mandatory access 
control system.
>> umm, its pretty obvious, want a picture? here:
>>
>> SELinux:
>> attacker --> kernel DAC/capability checks --> selinux access checks -->
>> capabilities granted.
>> systrace:
>> attacker --> systrace --> capabilities granted.
>>
>
> and? this is not an attack vector, this just describes how things
> work at some conceptual level. an attack is where you demonstrate
> how you exploit the above mechanism to gain privileges that weren't
> otherwise granted to you by the systrace policy. note that i'm not
> saying that such an attack doesn't exist, it's just that you have
> yet to demonstrate one.
>
>
Eh? that _is_ an attack vector. you are asking for a PoC exploit which 
is not something I'm interested in that sort of thing at all. Again, you 
do not need a reproducible exploit to have a broken model.
>>> <snip>
>>>
>> 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 :)
>>
>
> oh the tears of joy... can't believe you actually said that.
> more seriously, more on the blog.
>
>
I'm not sure why you can't believe I said that. grsec has several 
advantages over apparmor, the primary one probably being that it can 
actually do access control on the entire system rather that an 
app-by-app basis (which apparmor explicitly limit themselves to).. 
apparmor decided to build simplicity into their model instead of making 
their model extensive and simplifying the policy writing/generation. 
grsecurity has similar deficiencies, such as IPC. The reason is that 
grsecurity specifically targets system/app integrity and not information 
flow. The claim from the grsec author will be that IPC isn't a real 
attack vector, and in practice it might not be for more systems but 
there are many systems that are very sensitive to information flow and 
need IPC protection. grsecurity wouldn't be sufficient for those 
systems, it may be for others.
>> 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*
>>
>
> start here: http://marc.theaimsgroup.com/?l=dailydave&m=112638071303189&w=2
>
> and please tell me you're not running with a+x.
>
>
The answer to that email is simple. You don't need an access control 
matrix of a million elements if you have equivalence classes (something 
widely used in SELinux), see
http://securityblog.org/brindle/2006/03/23/the-myth-of-least-privilege-or-why-we-love-equivalence-classes/
the a+x in $PATH argument is a strawman, anything you run is under your 
privilege level (whether that's the DAC uid or the MAC domain (or 
however it is implemented))
> <snip>
> actually, the folks who wrote CC are very clever in my opinion, they
> have clearly understood what information security is all about and it's
> not their fault that many 'experts' of our time sell their concepts to
> completely wrong markets.
>
>
Glad to hear it...
>> 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.
>>
>
> i was saving this for the blog, but since you've brought it up...
>
> you've just proved how dangerous spreading false sense of security
> is. the targeted policy you're talking about does not give any real
> security and coming from a self-described expert on selinux, it's
> really disheartening to see as you should know better than that.
>
>
Once again, you are confusing policy and mechanism. Just because the 
targeted policy doesn't restrict everything on the system doesn't say 
anything at all about the mechanism. Second, the targeted policy never 
claims to protect everyone from everything, quite the opposite, the name 
"targeted" pretty clearly states that certain things are restricted. 
Now, the difference between the selinux targeted and other systems is 
that with the targeted you can actually analyze the policy and ensure 
that the targeted domains can't affect the integrity of the rest of the 
system, which is impossible with path based systems.

Also, where have I ever said that I'm an expert on security or selinux? 
I do not appreciate blatant attempts to misinform or discredit people, 
don't do that.
> it is a bandage for the utter usability mess that selinux is and
> 'everyone' had complained about. practical example, what does
> restricting nscd by a policy help (and i'm generously ignoring the
> possibility of exploiting a kernel bug in a two stage attack) when
> an exploit can just go for an unconfined application (plenty of them
> left)? so yeah, a clear win and breaking new ground there... no.
>
On recent targeted systems most, if not all, network daemons are 
confined. Its pretty obvious that an "unconfined" application is... wait 
for it... not confined! wow,  I'm very glad that you can use a 
dictionary. I don't think anyone expects unconfined applications to be 
... well.. confined. If they do they've been grossly misinformed, I take 
no credit for anything 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 think you misunderstood me. i don't care what opinion you hold about
> grsec or apparmor or whatever as much as i care about not spreading
> false sense of security. you drew a clear and obvious line between
> selinux and the rest of the world ("grsec/apparmor implement one of the
> dumbest ideas in security", that's what you stated effectively), and
> that's simply not right so you will have to defend your opinion or eat
> those words, your choice.
>
>
I think you misunderstanding. I claim that path based access control is 
flawed for all the reasons I've listed (which you haven't refuted) at an 
ideal and philosophical level. There are a number of practical and 
technical issues with this as well (see the LSM list over the last week 
or so...) But I haven't talked about those at all, I'm not sure where 
you are coming from here.
>> 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 effsective.
>>
>
> although i wasn't talking about grsec per se, but now you made me curious.
> what the heck is 'lightweight security'? and how come that a system
> implementing one of the dumbest ideas in security can be effective?
> effective at what? being dumb? or perhaps, providing 'security'? what
> would that 'security' mean then and why cannot selinux provide it?
>
>
Once again, security is about your requirements and possible tradeoffs.
>> 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?
>>
>
> you already pulled that feat off, so i'm left with the task of putting
> the pieces of the puzzle together for all to see.
>
Ok, have fun with that. I'm going to be gone after today until next week 
so don't misconstrue my lack of reply as assent.
-- 
gentoo-security@g.o mailing list