From: yersinia (yersinia.spirosgmail.com)
Date: Tue Apr 07 2009 - 05:47:25 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

2009/4/2 <pageexecfreemail.hu>

> On 30 Mar 2009 at 16:55, Travis wrote:
>
> > On Sat, Mar 28, 2009 at 08:48:36AM +0200, pageexecfreemail.hu wrote:
> > > do 'exploitable kernel bugs' count?
> >
> > Searching the NVD/CVE shows 5 vulns.
>
> you might want to re-read that 'kernel bugs' part. SELinux != kernel
> by any stretch of the word.
>
> > Are there more? Possibly, I don't know.
>
> possibly, the same search engine holds the answer. at least for those
> bugs that the kernel devs decided to document.
>
> > Sure, it's bad to introduce a vulnerability. Introducing a kernel
> > vulnerability is especially bad. They definitely count. Hopefully,
> > as the code matures, we'll see fewer of them. Yes, it's embarrassing
> > for a security enhancement to actually introduce vulnerabilities.
>
> it's irrelevant how many bugs SELinux introduces because the rest of
> the kernel has orders of magnitude more itself.
>
> > Let's address the (implied) argument here; this is kernel code, in C,
> > designed to limit the scope of damage if someone siezes control of a
> > program's execution context. The argument is that if there are any
> > vulnerabilities introduced by the implementation, it is inherently
> > flawed and must be rejected.
>
> the argument is not about SELinux bugs but exploitable kernel bugs.
> any one of them completely undermines SELinux (obviously not counting
> those that are not reachable due to kernel or policy configuration).
>
> seizing control of a programs's execution context means that the attacker
> can directly exploit the kernel bugs from there. in other words, for the
> situation you mention, SELinux is inherently flawed (which as Peter Busser
> mentioned elsewhere is no surprise, MAC was designed for a different
> environment).
>
> but you can prove your statement if you want: create an exploitable service
> on your personal box that holds your most valuable data and open up access
> to the internet (if you're lazy, just open up ssh and give the world a
> shell
> prompt) and keep running it for the rest of your life. make sure you apply
> the same SELinux policy to it that you use on your otherwise sensitive apps
> (such as web browser, mail/chat clients, etc).

>
> if you actually believe your own words, then you're not going to find fake
> excuses for not doing this experiment. after all, SELinux protects you even
> 'if someone siezes control of a program's execution context', right?
>
> > Does an exploitable implementation bug invalidate the entire
> > idea/design/system? I'm not convinced that's true. If it were, the
> > same argument would apply against, say, OpenSSH.
>
> what is flawed is your use of SELinux. as for openssh, one day you might
> learn about the aftermath of CVE-2001-0144 then you'll be in a better
> position
> to argue about the consequences of implementation bugs.
>
> > Even on an implementation level, I think the real question for a
> > security subsystem is whether the net result is going to be an
> > improvement in security or not. I think this is the core of the
> > disagreements here. It's easy to count the vulnerabilities found in
> > the implementation (it's also relatively easy to fix the code, once
> > they are disclosed). But it's harder to quantify the benefit of
> > _containing_ an intruder who manages to pop a vulnerable service.
> >
> > IMHO, this is what I think is really meant by "defense-in-depth"; not
> > band-aids deployed in middleboxes with crossed fingers to hopefully
> > protect crappy code, but a real layer of access control that can
> > really limit an adversary after an intrusion. I'm still not convinced
> > the idea is a bad one, even if the implementation isn't perfect.
>
> the ball is on your side now to prove it.
>
>
SIA
There is someone that have already done it, other that write about
this topic (
http://etbe.coker.com.au/2007/10/10/how-se-linux-prevents-local-root-exploits/
)

Try the selinux play machine - it's only access is root with uid 0.
http://www.coker.com.au/selinux/play.html

>
> _______________________________________________
> Dailydave mailing list
> Dailydavelists.immunitysec.com
> http://lists.immunitysec.com/mailman/listinfo/dailydave
>
>

_______________________________________________
Dailydave mailing list
Dailydavelists.immunitysec.com
http://lists.immunitysec.com/mailman/listinfo/dailydave

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]