Walsh: Introducing the SELinux Sandbox

Posted May 27, 2009 22:29 UTC (Wed) by foom (subscriber, #14868)
In reply to: Walsh: Introducing the SELinux Sandbox by PaXTeam
Parent article: Walsh: Introducing the SELinux Sandbox

In your world, I guess we should get rid of all access restrictions in Linux, because the kernel I'm
running may have some exploitable vulnerabilities, so any access restrictions are completely
meaningless.

In the real world, people do run multiuser linux machines.

Security is not black and white, there is such a thing as more secure and harder to break into.

This is one more link in the chain, designed to help secure single-user machines. Now, not only
do you need to be running a vulnerable JPEG rendering library to have your files stolen, you
*also* need to be running a kernel which is exploitable in the limited attack surface presented to
the JPEG decoding process.

Surely it's a good thing to attempt to limit the attack surface?

> where did you say your most valuable personal box can be accessed again ;)?

Here:
http://www.coker.com.au/selinux/play.html

(okay, it's not mine :)

to post comments

Walsh: Introducing the SELinux Sandbox

Posted May 27, 2009 23:03 UTC (Wed) by PaXTeam (guest, #24616) [Link] (15 responses)

> In your world, I guess[...]

in my world, you guess wrong ;). in my world, (exploitable) bugs are a fact of life and i've been working on intrusion prevention technologies for some years now.

> In the real world, people do run multiuser linux machines.

and did someone say otherwise? ;)

> Security is not black and white, there is such a thing as more secure and harder to break into.

did someone say otherwise? how did this even come up in this thread?

> you *also* need to be running a kernel which is exploitable in the
> limited attack surface presented to the JPEG decoding process.

you sound as if it was that hard to find such a kernel. here's the breaking news for you: *any* kernel in existence has exploitable bugs in it. exploitable 'in the limited attack surface presented to the JPEG decoding process'. remember do_brk? or mremap? are you gonna ban memory allocation? it's especially funny that you talk about attack surface here when the original solution (seccomp) did in fact have a meaningful reduction, unlike this alternative.

> Surely it's a good thing to attempt to limit the attack surface?

yes, except SELinux or this sandbox don't do it. the proper way is to prevent arbitrary code execution as a start or make kernel bugs unexploitable (for privilege elevation at least).

> http://www.coker.com.au/selinux/play.html

which part of 'most valuable personal box' was not clear ;)? or are you suggesting that all SELinux can protect in real life is worthless data? the fact that you're not putting your own box at risk speaks for itself.

Walsh: Introducing the SELinux Sandbox

Posted May 28, 2009 0:50 UTC (Thu) by jamesmrh (guest, #31622) [Link] (14 responses)

> the proper way is to prevent arbitrary code execution as a start or make kernel bugs unexploitable (for privilege elevation at least).

If you have patches which can be upstreamed, please post them to lkml and work with the x86 and security folk.

I've not been involved in prior discussions of Pax patches specifically, so I don't know what the overall status is, but I'm sure more must be possible than having two groups sitting apart like this.

Walsh: Introducing the SELinux Sandbox

Posted May 28, 2009 17:33 UTC (Thu) by PaXTeam (guest, #24616) [Link] (13 responses)

http://lwn.net/Articles/315164/

Walsh: Introducing the SELinux Sandbox

Posted May 28, 2009 21:57 UTC (Thu) by nix (subscriber, #2304) [Link] (12 responses)

So... you've never tried to upstream your changes and are in fact actively
against it, you complain when people implement variations on them because
they're not done *exactly* the way you'd like (e.g. exec-shield)... and
then you complain that kernel security isn't good enough and that people
don't listen to you.

Just so that's clear.

Walsh: Introducing the SELinux Sandbox

Posted May 28, 2009 22:11 UTC (Thu) by PaXTeam (guest, #24616) [Link] (5 responses)

> you've never tried to upstream your changes

correct.

> and are in fact actively against it,

not correct.

> you complain when people implement variations on them

not correct.

> because they're not done *exactly* the way you'd like (e.g. exec-shield)...

not correct.

> and then you complain that kernel security isn't good enough

correct.

> and that people don't listen to you.

not correct.

> Just so that's clear.

is it? ;)

Walsh: Introducing the SELinux Sandbox

Posted May 28, 2009 22:58 UTC (Thu) by nix (subscriber, #2304) [Link] (4 responses)

Well now you're arguing against your own stated positions in comments
here, so I'll leave you to argue with yourself.

Walsh: Introducing the SELinux Sandbox

Posted May 28, 2009 23:56 UTC (Thu) by PaXTeam (guest, #24616) [Link] (3 responses)

> Well now you're arguing against your own stated positions in comments
here,

then you can surely quote me back point by point? ;) unless of course you don't want to risk to fall on your own sword again, as you did in the past so many times (in this very thread too ;).

Walsh: Introducing the SELinux Sandbox

Posted May 29, 2009 7:00 UTC (Fri) by nix (subscriber, #2304) [Link] (2 responses)

I simply can't be bothered. Life is much, much too short. If this rubbish
was worthy of detailed cites I'd have given them.

Walsh: Introducing the SELinux Sandbox

Posted May 29, 2009 7:54 UTC (Fri) by PaXTeam (guest, #24616) [Link] (1 responses)

In other words, you were just trolling all the time as usual.

Just so that's clear.

Walsh: Introducing the SELinux Sandbox

Posted Jun 2, 2009 12:51 UTC (Tue) by nix (subscriber, #2304) [Link]

No, I'm smashed on hayfever drugs and just spent a day in hospital after
yet another bout with anaphylactic shock. I have no intention of wasting
time searching a site that doesn't do per-author search to prove to
someone what his own words say. If you can't remember what you said a day
or less ago, I don't care.

Walsh: Introducing the SELinux Sandbox

Posted May 28, 2009 22:27 UTC (Thu) by spender (guest, #23067) [Link] (5 responses)

The PaX team wasn't involved in this, but I had actually asked Linus back in 2004 if PaX would ever be accepted into the mainline kernel. His response meant that essentially no feature of PaX at the time (except for perhaps PAGEEXEC on some non-x86 architectures) would be accepted. For record-keeping purposes, here's the mail:

Date: Sun, 12 Dec 2004 10:35:53 -0800 (PST)
From: Linus Torvalds <torvalds@osdl.org>
To: spender@grsecurity.net
Subject: Re: memory leak in drivers/net/wan/cosa.c

On Sun, 12 Dec 2004 spender@grsecurity.net wrote:
>
> While I'm on that subject, would it ever be possible to PaX
> (http://pax.grsecurity.net) merged into the mainline kernel?

Hmm.. I usually don't merge stuff unless users actually ask for it, and I
haven't seen much discussion there.

That said: I absolutely _detest_ anything that does x86 segmentation. I
actually try to kill all uses of segmentation, it's a horrid thing, and
it's finally going away. NX makes the last reason for it obsolete, and I
don't want to add kernel code for something I dislike _and_ believe has no
future.

Also, randomization is similarly on my list of "absolutely evil" cases,
simply because it makes one of my pet things unusable: prelinking. I think
program startup costs are about the most importatnt things there are in
life (well, in _kernel_ life, at least), so pre-linking ends up being
something I consider very important. That means that randomization falls
under the heading of "not for regular use" as far as I'm concerned.

Of course, people who are really security-conscious may well want to do
randomization, I just dislike it as a _standard_ thing. But if it isn't
standard, then it has little point, methinks - the whole point is to make
it harder to attack standard installations, no?

> If you would be interested in merging at least parts of the code, the
> PaX team would be willing to do the work to have it included.

I don't have anything against merging individual features that would make
it easier for you guys, but see above on what I consider to be primary
objectives: no obsolete hw features that mess up generic code, and fast
process linkage startup. Which is why I tend to like a static NX kind of
setup.

But any particular detail I'm more than happy to have argued for, for
example:

> BTW, in arch/i386/kernel/entry.S, there is an information leak of the
> ebp kernel register. A fix for it has been in the PaX patch, but
> basically the solution is to add "xorl %ebp,%ebp" after "jne
> syscall_exit_work".

Yes, that seems to be a perfectly valid thing to do, although the only
thing it leaks is just the thread info address, so it's not like it leaks
random information that might contain any interesting data depending on
which system call it was. But an xorl is certainly not expensive, and it's
nicer to not leak anything at all.

Linus

Walsh: Introducing the SELinux Sandbox

Posted May 28, 2009 22:38 UTC (Thu) by dlang (guest, #313) [Link] (1 responses)

am I reading the same e-mail that you are?

I see Linus arguing against specific features, but saying

quote:
I don't have anything against merging individual features that would make
it easier for you guys, but see above on what I consider to be primary
objectives: no obsolete hw features that mess up generic code, and fast
process linkage startup. Which is why I tend to like a static NX kind of
setup.

But any particular detail I'm more than happy to have argued for, for
example:

endquote

that sounds to me like he doesn't agree with everything, but is very willing to look at individual features, some of which can be accepted, others of which may not be.

the fact that nobody has made the effort to break up the PaX changes and present each one on it's own merits does mean that they will definantly not go in as-is. if other people create patches (either completely independantly, or based on the concepts of PaX) they are going to be different, but since theya re trying to address the same problem it's very likely that they will end up being very close to the same

Walsh: Introducing the SELinux Sandbox

Posted May 28, 2009 22:59 UTC (Thu) by spender (guest, #23067) [Link]

As I had mentioned, nearly all of the features of PaX at the time were covered under those two things Linus said he wouldn't accept. The only remaining feature that he would accept would have been PAGEEXEC for non-x86 architectures -- code that nearly no one uses, changes very rarely, and wouldn't have saved the PaX team any time by merging it into mainline. Also consider that at the time, some of those architectures weren't capable of sustaining non-executable pages in userland without some kind of emulation on glibc, which means the changes to those architectures wouldn't have been accepted either. Furthermore, regarding the merging of small, individual changes, the PaX Team already discussed that here: http://lwn.net/Articles/315164/

I thought it was clear already, but hopefully that resolves any dangling questions.

-Brad

Walsh: Introducing the SELinux Sandbox

Posted May 28, 2009 23:33 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses)

That said: I absolutely _detest_ anything that does x86 segmentation.

Yet PAE does segmentation, and Linus accepted that.

He does sometimes change his mind, y'know.

Walsh: Introducing the SELinux Sandbox

Posted May 28, 2009 23:44 UTC (Thu) by PaXTeam (guest, #24616) [Link] (1 responses)

> Yet PAE does segmentation,

haha, if anyone had any doubt about your expertise in these security matters, you cleared that all up in those four words ;)

Walsh: Introducing the SELinux Sandbox

Posted May 29, 2009 6:59 UTC (Fri) by nix (subscriber, #2304) [Link]

I never claimed to be any kind of expert on the innards of x86, and I'm
high on hayfever drugs.