Dailydave mailing list archives

By Date

By Thread

Re: In defense of Mandatory Access Control,

On 30 Mar 2009 at 16:55, Travis wrote:

On Sat, Mar 28, 2009 at 08:48:36AM +0200, pageexec () freemail 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.

Attachment: WPM$219F.PM$
Description: Mail message body

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

By Date

By Thread

Current thread:

• Re: In defense of Mandatory Access Control, pageexec (Apr 02)
  • Re: In defense of Mandatory Access Control, yersinia (Apr 07)
    • Re: In defense of Mandatory Access Control, pageexec (Apr 07)