Walsh: Introducing the SELinux Sandbox

Posted May 28, 2009 22:27 UTC (Thu) by spender (guest, #23067)
In reply to: Walsh: Introducing the SELinux Sandbox by nix
Parent article: Walsh: Introducing the SELinux Sandbox

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

to post comments

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.