Walsh: Introducing the SELinux Sandbox

Posted May 27, 2009 18:31 UTC (Wed) by Kit (guest, #55925)
In reply to: Walsh: Introducing the SELinux Sandbox by PaXTeam
Parent article: Walsh: Introducing the SELinux Sandbox

>> which causes arbitrary code to be executed on your system, which might
>> then do something like install a spam bot or post your private keys to
>> some irc channel.

>...or exploit a kernel bug, disable SELinux, escape the sandbox and all
> the other bad things you're saying you're protecting users from.
Which would be harder to pull off than not having to find and successfully exploit a kernel bug.

>> This is an application of the principle of least privilege[...]

>instead it's giving innocent users a false sense of security. but if
>you actually believe your own statements, you're free to give the
>whole world arbitrary code execution rights on your personal box and
>see how long it'll last ;).
Any false sense of security would be the fault of the presentation, not the implementation. Would it be fool proof? Of course not, nothing is. Would it raise the bar, making it less likely for your system to be successfully compromised? Yes, at least once the implementation is matured and when used properly.

to post comments

Walsh: Introducing the SELinux Sandbox

Posted May 27, 2009 20:00 UTC (Wed) by PaXTeam (guest, #24616) [Link] (20 responses)

> Which would be harder to pull off than not having to find and successfully exploit a kernel bug.

that is, 'doing something is harder than not doing it'. did you try to say something meaningful here? and out of curiosity, what do you know about finding and exploiting kernel bugs? so far you seem quite confused between 'vulnerability' and 'exploit', so it might be a good idea to clear those terms up first.

> Any false sense of security would be the fault of the presentation, not
> the implementation. Would it be fool proof? Of course not, nothing is.
> Would it raise the bar, making it less likely for your system to be
> successfully compromised? Yes, at least once the implementation is
> matured and when used properly.

i don't follow you here. how can the implementation (of what, btw? kernel? SELinux? this new sandbox?) both mature and not be fool-proof at the same time? obviously exploitable kernel bugs will never go away, nor will the false sense of security, apparently. where did you say your most valuable personal box can be accessed again ;)?

Walsh: Introducing the SELinux Sandbox

Posted May 27, 2009 20:54 UTC (Wed) by nix (subscriber, #2304) [Link] (2 responses)

Given that it is likely almost impossible to eliminate *all* security bugs
in Linux, even all root-granting bugs in the kernel, and is certainly
impossible to prove that they're all gone, what would you recommend? That
we give up implementing *any* other security mechanisms until, what? Until
you say the kernel is secure enough now?

Perhaps we should just junk Linux and switch to a proper capability-
based-security system, that's of course thoroughly non-POSIX but at least
can be proven secure more easily... and then realise that SMM holes and
FireWire's lovely remote-DMA features mean that we're *still* insecure...

Walsh: Introducing the SELinux Sandbox

Posted May 27, 2009 22:10 UTC (Wed) by PaXTeam (guest, #24616) [Link] (1 responses)

> what would you recommend?

that you take that risk into account and live with it. instead of burying your head in the cushy cloud of false sense of security.

> That we give up implementing *any* other security mechanisms until, what?

security mechanims obviously must be implemented (you may have heard of intrusion prevention systems? such concepts are equally applicable to kernel land as well). fake mechanisms should not be, and especially they should not be presented to the gullible public as something they are not. both SELinux and this sandbox fail fatally if the threat model includes arbitrary code execution (which is what James Morris said). and of course you can prevent arbitrary code execution with much less than the overly complex SELinux. unfortunately such environments are less than usable for the average person, so this problem is far from solved.

> but at least can be proven secure more easily...

no they cannot. for any non-trivial system (read: something you'd actually install and use on a daily basis as you do now) the complexity of the code that solves our problems cannot be really reduced (that's why microkernels, hypervisors, 'solution' du jour are not more secure either).

> and then realise that SMM holes and FireWire's lovely remote-DMA
> features mean that we're *still* insecure...

SMM 'holes' are irrelevant in the real world as exploiting/abusing them requires privileges that you want to get in the first place normally. firewire et al. imply a different threat model (hw) and hence different solutions (physical protection, nothing unsolvable there if you can pay the price).

Walsh: Introducing the SELinux Sandbox

Posted Jun 1, 2009 12:53 UTC (Mon) by hozelda (guest, #19341) [Link]

>> that you take that risk into account and live with it. instead of burying your head in the cushy cloud of false sense of security.

The risk of finding kernel bugs and exploiting them varies over time. Most security measures only address certain types of attacks anyway and so leave holes as well.

I believe selinux is a useful cog in the security machinery because it can limit the damage of exploited userland applications. It's a very useful function, for example, to keep a browser from trashing all your files, and this can happen without a kernel exploit. There are a lot more lines of app code written than kernel code. selinux can provide protection for failures in the former (exploits as well as out-of-control bugs).

To rephrase, selinux allows mitigating damage from vulnerabilities that can happen from much of the software on the system. In exchange, to preserve selinux itself, you have to protect the entirety of the kernel, but this still forms a small fraction of all the code on a machine (and it is code that has attracted a larger than average number of eyeballs and expertise).

Much of the kernel source added periodically is for drivers. Many drivers never even come into play on any given system.

>> you may have heard of intrusion prevention systems? such concepts are equally applicable to kernel land as well

This is orthogonal to selinux. It does not replace selinux functionality.

>> fake mechanisms should not be, and especially they should not be presented to the gullible public as something they are not

Legitimate complaint, but I have seen a number of people on this thread and elsewhere accept the limitations of selinux. Who is lying to the public?

>> both SELinux and this sandbox fail fatally if the threat model includes arbitrary code execution (which is what James Morris said). and of course you can prevent arbitrary code execution with much less than the overly complex SELinux

But this is again orthogonal to what selinux does.

>> the complexity of the code that solves our problems cannot be really reduced (that's why microkernels, hypervisors, 'solution' du jour are not more secure either)

From wikipedia: "Many definitions [of 'complexity'] tend to postulate or assume that complexity expresses a condition of numerous elements in a system and numerous forms of relationships among the elements."

You can reduce complexity by managing the number and quality of the parts and the inter-relationships among them.

Looked at differently, it's not hard to imagine that you can make something more complex (and buggy) without gaining any benefits; hence, this means that not everything is at the same level of complexity or correctness [which implies some things are better than others].

Walsh: Introducing the SELinux Sandbox

Posted May 27, 2009 22:29 UTC (Wed) by foom (subscriber, #14868) [Link] (16 responses)

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 :)

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.