Walsh: Introducing the SELinux Sandbox

Posted May 28, 2009 19:31 UTC (Thu) by hozelda (guest, #19341)
In reply to: Walsh: Introducing the SELinux Sandbox by spender
Parent article: Walsh: Introducing the SELinux Sandbox

>> What I'm saying is, I hope the people pushing SELinux get out of the habit of throwing around phrases that exaggerate the effectiveness of SELinux or suggest that it provides a guarantee of anything. I made the same request years ago when I published my local root exploit that disabled SELinux (and every other LSM security module) -- that apparently had no effect on them, nor has the recently published remote root + SELinux disabling exploit.

I see two things.

One, Red Hat talks about a model and you talk about an implementation. Your exploits are about bugs and not about the model.

Ironically, I'm fairly sure you aren't even talking about a specific implementation (of a full system or of software) since you mention an exploit from years back, yet talk as if the new system is the same one.

Further, you talk about SELinux as being a level of security and not being the whole system ("disable SELinux"). Using that interpretation, you didn't even show a flaw in the SELinux implementation. You showed a flaw in the software that enables (turns on or off) the SELinux security.

>> Instead it was 'business-as-usual' for the vendors: just fix the remotely exploitable vulnerability that we classified as a denial-of-service (as is done with nearly all exploitable vulnerabilities for which there doesn't exist public code exploiting them), hope nobody makes a fuss about it, and move on.

Do you know of any vendor that make a "fuss" about every bug they fix?

Do you know of a vendor that makes a greater deal about fixing bugs than does Red Hat and, in general, the open source world?

Most other vendors don't even make the slight attempt at "fuss" by showing the world the bug they just fixed. Red Hat and company make a certain fuss about every single bug they fix because they take the time to document them all publicly and keep this ongoing information public as they "move on" to the next job at task.

>> This irresponsible mindset isn't confined to SELinux: there are others who erroneously believed that information of different security levels could be compartmentalized by using virtual machines. It should be clear from the above mentioned exploits for Xen and VMWare that this view is just as foolish.

You should have continued talking about every other virtual machine on the planet.

In fact, mentioning VMWare is redundant since we already know we can't trust closed source companies or their binary-only products.

And speaking of not being able to trust closed source companies (eg, Microsoft) or their products...

>> Some of PaX's features are already tackling these problems, and continue to improve

What in the hxxx is PaX?

I went over to the pac grsecurity etc site. I can't believe you allow (broken) links on your site that possibly suggest you can (a) secure OR (b) independently implement Windows (the latter being an illogical statement).

It's difficult to take you seriously (assuming I was still taking you seriously). Do you honestly think anyone working outside of Microsoft has a shot (a shot, if perhaps even lower than one google to one) at securing Windows?

I am hoping I misunderstood the low content information bits I read on that site and that you will clarify just what statement you are trying to make with respect to anyone being able to secure Windows or else re-implement it (which is a nonsensical statement anyway).

[I'm assuming you own that site. If not, then can you still address these concerns I have since you appear to know a lot about this PaX?]

to post comments

Walsh: Introducing the SELinux Sandbox

Posted May 28, 2009 20:19 UTC (Thu) by hozelda (guest, #19341) [Link] (7 responses)

[I said] >> One, Red Hat talks about a model and you talk about an implementation. Your exploits are about bugs and not about the model.

Same caveat applies as discussed above: http://lwn.net/Articles/335115/

[I said] >> I went over to the pac grsecurity etc site. I can't believe you allow (broken) links on your site that possibly suggest you can (a) secure OR (b) independently implement Windows (the latter being an illogical statement).

I thought, at the time I wrote the above comment, that the wording on the website was a bit misleading, but if I'd know what PaX was, I might agree that the comments about "Windows .. implementation" on the website refer to PaX and not Windows itself. My bad, I think.

I still want to know if the intention was to suggest that Windows can be secured in any way by a third party.

Walsh: Introducing the SELinux Sandbox

Posted May 28, 2009 21:45 UTC (Thu) by spender (guest, #23067) [Link] (6 responses)

If you want to know what PaX is/does, there's the bunch of documentation on the first link on the page: http://pax.grsecurity.net/docs/
Additional information is in the configuration help for each of its options in the patch itself.

As for the Windows comments in your post(s), I don't see what's so shocking about saying certain third parties have implemented some of same techniques implemented in PaX. Take WehnTrust for instance, which implemented ASLR on Windows (even implementing RANDEXEC through its own version of vma mirroring used in PaX). The source is available -- it's actually a nice piece of work, considering that it's more difficult (but more interesting/rewarding) to implement security in Windows than Linux as you have to get around the problem of not having any source. The person who wrote it now works for Microsoft, which brings me to my next point: the anti-Microsoft view you have of their security is pretty outdated. They've actually been taking security seriously for some time now (which I can't say for the official policies of Linux kernel developers) and employ a large number of really bright security experts (like Matt Miller, the WehnTrust author).

At the same time, it's obviously true that some (or most) of the third party security improvements for Windows claim more than they're actually capable of. There was a particular product I won't mention the name of that claimed detection/prevention of "ret2libc attacks". Since noone else has actually solved this problem yet, I was curious to see what the "protection" entailed. It turned out that the software was just checking to see if the return address for an API call (only the ones it cared about enough to hook) pointed into the stack or to a function prologue -- not true detection/prevention, as it can be worked around by techniques that have been public for years.

I don't envy the monstrous task Microsoft has of improving their security. Any improvements have to be done in such a way that doesn't break application compatibility. Given the amount of software on Windows, most of which only exists in binary form and where many of the authors are long gone -- it's no small feat. In some cases their improvements turn out to be unpopular (UAC) or they have to sacrifice some additional security. This is no different from any other major vendor though -- Red Hat sacrificed some additional security in their Exec-Shield implementation in the name of perceived application compatibility.

-Brad

Walsh: Introducing the SELinux Sandbox

Posted May 29, 2009 1:01 UTC (Fri) by hozelda (guest, #19341) [Link] (5 responses)

Hey Brad, I got a "you are embarrassing yourself" email from someone providing almost no details. You can probably guess how much weight I give emails that are FUD-secretive in nature. [It's my open source mentality, I think.]

In any case, this event reminds me that I am willing to reply on specific points without feeling the obligation to become an expert on every facet of the discussion. This does mean I might misfire, but I encourage anyone to always try to correct errors in postings that bother them enough. This helps the author and the readers coming after that may also not be experts either.

Excuse me if I was harsh and am not aware of all the good work you and anyone else may have done.

>> As for the Windows comments in your post(s), I don't see what's so shocking about saying certain third parties have implemented some of same techniques implemented in PaX.

Nothing wrong. What happened is that I became suspect over your motives and realized that, regardless of your motives, you were providing material that others out of the spotlight could point at to say, "see all that controversy surrounding Linux/SELinux". Taking everything into account, I thought maybe PaX was a product intended to compete directly with SELinux and had to ask just how a third party could ever believe they could solve Microsoft's problems for Microsoft. Some of their "problems" are based on business decisions which involve protecting monopolies -- eg, by keeping source closed and by making it difficult to have the actual interfaces fully resolved by third parties.

Microsoft can certainly try to leverage PaX. We just can't say nearly as much about the final product Microsoft comes up with without having access to the full source.. A single line of code, or a single module certainly, can bypass apparent security. The task of reverse engineering is an art. The test space is virtually infinite and you have a much longer less precise task ahead without the benefit of source code (including of compilers, etc). Some of the prodding is even illegal according to their EULA, meaning that the number of people even attempting such a task will be further limited.

>> considering that it's more difficult (but more interesting/rewarding) to implement security in Windows than Linux as you have to get around the problem of not having any source.

Just want to mention that interesting in one sense is not interesting in another.

>> The person who wrote it now works for Microsoft

See, even that individual probably preferred to see Microsoft's source. I mean there is a reason the FOSS world shares source. "Interesting" is great and all, but..

..show me the source.

>> the anti-Microsoft view you have of their security is pretty outdated

I did not intend to appear to mock their past (too much). I said that *all* closed source vendors are untrustworthy. This is an academic pov. It's like the example you gave where someone made outrageous claims but kept the magic secret.

Put up (the source code) or shut up is my reply to anyone that wants trust, especially when the software is that complex. Open review is the judge.

In Microsoft's case, seeing some code (let's assume we get access) doesn't convince me an iota that this is what they are shipping, so while I could critique, I would not for a second believe I was actually getting the information I would need to make a security decision in the way I could if I had source.

I don't trust closed source (that I can't change and build to verify). I might run the binaries and accept certain risks, however, but that is a different issue to having the confidence the comes only from open source code.

>> They've actually been taking security seriously for some time now (which I can't say for the official policies of Linux kernel developers)..

That's an unfounded statement. Linus and many Linux developers have taken security more seriously than many that will ever pass through Microsoft.

You can't just start taking security seriously after so much has been invested and pretend you care more about security than those that have taken it more seriously from the start.

Microsoft has a long history of deceptive marketing shrewdness. Their engineers are not the ones making statements on behalf of Microsoft. In fact, their engineers don't make the final decisions in any way.

>> and employ a large number of really bright security experts

I would bet a farm that Microsoft cannot match the number of really bright security experts that currently do or will work on Linux. [Academic institutions, private security researchers, major companies with lots of expertise on staff.. etc, all have access to Linux but not to Windows.]

>> Any improvements have to be done in such a way that doesn't break application compatibility.

Every update Microsoft sends out breaks something, generally speaking. Vista was a mess, but you don't have to be that obvious in one large shot to know that lots of things can break when you don't test for them (conduct analysis, etc). Fixing a bug in Windows will break software that was written with that bug in mind, for example.

Microsoft's interest is to their stockholders, not to the users. They don't give users the benefit of source code, for starters. The users have the source to Linux and their own best interests in mind.

Red Hat is kept in check (so long as they stick to their model) by the public, by the wide open source community. Who keeps Microsoft in check? Certainly not the public.

Closed source is magic. I don't trust it.

And everyone who has gone to work at Microsoft apparently also preferred not to take Microsoft at their word but rather wanted to see some source (of course, mere employees cannot expect to have control and knowledge over the final product because of access restrictions and inability to privately verify the bits through their personal compilation checks).

>> In some cases their improvements turn out to be unpopular (UAC) or they have to sacrifice some additional security. This is no different from any other major vendor though -- Red Hat sacrificed some additional security in their Exec-Shield implementation in the name of perceived application compatibility.

You still can't compare what you can't see with what you can.

[Broken record again: You don't know what Microsoft ships. You don't know their bugs or what process gives the final pass over their bits. Ditto for all their updates.]

To finish, I don't intend to be harsh to you. My beef, primarily, is with those that attack FOSS unjustly, eg, with whom I like to call Monopolysoft, with their dirty tactics, false promises, and lack of transparency.

[FWIW, they keep cutting back and losing quality individuals. Customers relying on them, a shrinking number, might not be thinking long term in putting all their eggs into a single basket.]

Walsh: Introducing the SELinux Sandbox

Posted May 29, 2009 2:33 UTC (Fri) by spender (guest, #23067) [Link] (2 responses)

A couple comments:

As mentioned on the PaX site, Microsoft has DEP (their HW-based PAGEEXEC implementation) and (a weak) version of ASLR. I had remembered reading that Server 2008 would prevent a service from respawning for a period of time if it had crashed multiple times within a short period of time (deterring bruteforcing of ASLR -- something vanilla Linux doesn't have yet) but when I went to look for a link about it last, I couldn't find one.

EULAs don't stop security researchers from doing their work, nor does not having the source. Reverse engineering has advanced quite a bit in the past couple years, as well as the state of art in decompilation. Tools like BinDiff makes vulnerability finding in patches much quicker, while the Hex-Rays decompiler does a decent job of turning x86 assembly into C-like code. The Windows implementations of DEP and ASLR are pretty well documented publicly. Several companies have published papers on them and techniques for defeating the protections (for instance, it took a while for both Microsoft and Linux vendors to figure out that having a make_stack_executable() function without any safeguards wasn't such a good idea).

I sometimes wonder if there's a 'bystander effect' or 'free rider problem' involved with the "many eyes makes bugs shallow" view. There's a lot more people having a feeling of security based on the assumption that other people are reviewing the source instead of them, then there are actually people reviewing the source. The reality is, even though you have the kernel source, I'm pretty sure you don't audit it for security vulnerabilities, and if you did, it'd be impossible for you to audit every single line of it yourself. So in the end, you're putting trust in some entity, whether it's Microsoft or Linux vendors. It's naive to think Linux vendors are somehow unlike Microsoft in that they don't care about their stockholders -- everyone's in it for the money.

I wouldn't bet the farm anytime soon (though you've restated the challenge, which was initially Microsoft employees vs employees of Linux vendors, collectively) -- I know quite a number of people in the security industry. I can name several exceptionally bright security experts working for Microsoft, but can only think of one among the Linux vendors, who works for SuSE. Indeed, there are other bright people in the industry that work on Linux security -- Julien Tinnes and Tavis Ormandy come to mind, but neither of them are employed by a Linux vendor. To me, that says something. After all, security should should be the responsibility of the vendor, not Google; just as it's Microsoft's responsibility, not Mcafee's or Symantec's. Also, as far as the commercial security industry goes, there's far more people looking for vulnerabilities in Microsoft's software than there are looking at Linux -- simply because exploiting Microsoft software is more profitable (the same goes for underground exploit writers).

Regarding:
> That's an unfounded statement. Linus and many Linux developers have
> taken security more seriously than many that will ever pass through
> Microsoft.
you've apparently missed several past discussions both on here and LKML. It's pretty much agreed upon by the security industry that the official policy of the kernel developers (intentionally covering up security vulnerabilities by fixing the bugs without mentioning security impact that they're aware of) is damaging to users. Linus was nominated last year for the "Lamest vendor response" award: http://pwnie-awards.org/2008/nominees.html#lamestvendor

You mentioned not knowing about what Microsoft ships in their updates -- in fact, the security industry has a pretty good idea about what's being shipped in the updates. A huge number of exploits are written based on diffing an old binary with a newly patched binary. Though silent fixes could easily work their way into a service pack, it's harder to work one into the small patches that go out each month. The patches that are released are marked as security fixes. Sometimes obviously they get their security classification wrong and rightly get called to task for it. Of course, they seem to do a better job of it (again, this goes back to why it's important for the Linux vendors to have security experts on staff) than the tendency to call most vulnerabilities in the Linux kernel just "denial of service", when they're exploitable in reality. This has been commented on several times by several security experts. Three examples:
http://kernelbof.blogspot.com
http://www.security-express.com/archives/bugtraq/2006-07/...
http://securitywatch.eweek.com/exploits_and_attacks/inter...

> Closed source is magic. I don't trust it.

In summary, everything is magic -- verify ;)

-Brad

Walsh: Introducing the SELinux Sandbox

Posted May 29, 2009 3:10 UTC (Fri) by spender (guest, #23067) [Link]

Small update:
Though I still can't find the original link I read where it discusses "windows service recovery" as a useful/necessary addition to ASLR, I did find: http://technet.microsoft.com/en-us/library/cc262589.aspx
which shows how it's configured. By default in Windows 2003 and up, a service is allowed to crash 3 times, with a minute in between crashes. After the third crash, the service won't be restarted (thus deterring an ASLR bruteforce).

Given the recent discussions on LKML of quality of randomness for ASLR, I'm surprised no one brought this up. After all, randomness quality isn't of huge concern when nothing stops you from running your exploit as many times as it takes to get the addresses right. Nergal wrote his segvguard module years ago when he wrote his classic ret2libc paper, and similar code has been in grsecurity for years as well. Even if a kernel solution isn't used, it seems like it'd be a good job for a TCP wrapper like xinetd. That still doesn't help suid binaries, though.

-Brad

Walsh: Introducing the SELinux Sandbox

Posted May 29, 2009 5:03 UTC (Fri) by hozelda (guest, #19341) [Link]

The EULA does slow down work.

I also think you might be a little over-enthusiastic if you were suggesting that the reverse engineering jobs being undertaken will rival source code access. Just consider the amount of work produced per unit time by the FOSS world vs. the "useful" work being achieved by the underground or by the research world focused on Windows. Clearly one type of work is much more difficult (ie, the one without source code access).

You have high esteem for the top researchers but perhaps miss out on the value and contributions from those not known in the industry. Not to drag SELinux back into this, but a bug fix can have many repercussions, including fixing security issues in the making (not yet analyzed by black hats or even by expert white hats because of information overload). Many people work on their concept of correctness and don't stop to categorize something as security related.

Remember that it takes much more time to develop an exploit usually than it does to fix the bug. With two competent parties analyzing code, which is more likely to finish first, on average?

In fact, you get something of a race to reporting bugs in the FOSS world (to at least get credit) because it is so much quicker to do this than to build an exploit. In the closed source world, you have lots of time to build the exploit with much time left over to craft a business plan around the series of exploits you will build.

Also, the number of eyeballs matters. There is a reason FOSS is quick to fix problems and many times anticipates them, one way or the other.

Of course, if the reverse engineers had done their jobs (assuming it was easy), then they would be patching Microsoft's software for Microsoft just as quickly as is done for FOSS. [I was being facetious.]

You mentioned all the work being done for Windows. Well, I think as time approaches infinity, we see people moving off Windows and onto the more transparent Linux. Research advances more when you have access to the most information possible and then try to fill in those fewest number of remaining holes. This obvious conclusion is among many not escaping those slowly but surely moving to support and contribute to FOSS.

Mainly with Microsoft software in mind, I say that you don't need to (eg) overflow a stack to subvert security or disrupt privacy. You can do it right under people's noses, and it is difficult to catch this because nothing unordinary is happening among an ocean of more unordinary stuff flashing by at hundreds of millions of ordinary instructions per second or faster.

In short, I am not going to be convinced that the reverse engineering job is keeping a check on Microsoft no matter how many tools you mention, nor am I going to be convinced that reverse engineering is comparable to having source. It's one thing to find flaws (diff to help you out, etc). It's another to verify things are correct or are not misbehaving in places you haven't looked. Finding a gem vs accounting for everything in the land. [And surely, the tools don't get as much information as source code+binaries]

To belabor the point.. RE leads to much more information overload. You filter out much to focus on things of interest. If 80MB source patch for Linux is tough to follow.. if everyone is trusting everyone else to see source as you stated.. then how much more difficult is the case when you don't have source yet have lots of changes in binaries. Remember that binaries are updated while the system is running with no need to announce what is going on. The system software can piggyback on any network conversation in any way it wants. It's too large a space to track which is why just looking at the network is not enough, and the binaries clearly have not been deciphered completely. Spotting problems in diffs is much easier than understanding the base. How well does the research community know the Windows base? I don't think nearly well enough. [Eg, you invoke things that Microsoft themselves have stated about their products rather than pointing to an analysis of their binaries to actually show/prove X or Y property is there. With sarcasm.. Don't the reverse engineers know all about Microsoft products the way we know about Linux? Why can't we point out where Microsoft does this or that in actuality (not in theory nor in their marketing nor in their purposely scrapped projects), as we can for Linux, but instead rely on their cribnotes to the public? What kind of checks are those? Who cares that these dissembling tools have progressed "hugely" recently?]

As concerns Red Hat being a public corp just like Microsoft, I addressed that already by saying that the issue is about checks and balances (we look towards their businesses for that.. one relies on openness the other on closedness) and additionally that Microsoft has monopoly profits to protect.

Walsh: Introducing the SELinux Sandbox

Posted Jun 6, 2009 11:07 UTC (Sat) by willezurmacht (guest, #58372) [Link] (1 responses)

When a person jumps into a discussion which covers topics he isn't particularly knowledgeable of, it's a matter of humility, good manners and taste to avoid making claims and dogmatic statements, like you've done so far.

But, if you are in for being the comic relief here, I welcome you as our special open source Leeroy Jenkins. Neither Brad nor the PaX Team know what they are talking about! Go get 'em, tiger!

Walsh: Introducing the SELinux Sandbox

Posted Jun 6, 2009 16:35 UTC (Sat) by dlang (guest, #313) [Link]

exactly what knowledge do you have of the posters qualifications that makes it so clear that you should ridicule him/her that way?

Walsh: Introducing the SELinux Sandbox

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

In fact, mentioning VMWare is redundant since we already know we can't trust closed source companies or their binary-only products.

More generally, the claim (whether stated or implied is not relevant: this is the claim as everyone understands it) that security systems make is that modulo bugs they provide some level of security. Of course, unless the system is utterly trivial, there are always bugs: but that doesn't mean the system is useless. It just means that it cannot keep out a sufficiently determined attacker.

Brad and PaXTeam assert (although they will doubtless deny this as part of the charmless dance of evasion they both employ whenever their reasoning is faulty) that this renders all such security systems worthless. But this is nonsense. The lock on my front door will not keep out an attacker who is determined enough to wade through plant growth and break my kitchen window. This is easy to detect --- but my house security systems also won't keep out an attacker who cuts through the glass of the patio door, which can be done nearly silently with enough care. The thing is that most attackers simply aren't going to do that: it's difficult and annoying and they're more likely to simply skip the house and go on to the next one, unless this is a targetted attack. The only way to keep out targetted attacks from such people is to go and live on a military base: but that merely opens me to attacks from much more powerful actors, who in time of war are likely to attack the military base and take me out as collateral damage, without even meaning to, but who wouldn't bother attacking a single anonymous house in the suburbs.

If you are under targetted attack by a sufficiently determined and ingenious attacker --- the sort of person Brad appears to be considering, who is willing to search for new remote and local vulnerabilities, write exploits for them, and target specific sites with them --- then you're in serious trouble and the best thing to do is simply get off the net until they go away (this is hardly optimal, but improving it is really up to law enforcement or network infrastructure: there's nothing individuals can sanely do). In the case where the attacker finds an exploit for a new vulnerability and launches mass attacks with it, we are somewhat protected by techniques such as ASLR, which can make many classes of exploit more *likely* to fail: mass attackers are likely to give up and go on to the next host before then. This is exactly the same sort of 'defense in depth' with non-100%-perfect but make-cracks-harder systems that Brad has been disparaging. (The strange thing is that a lot of the defences in grsecurity are of this type, so Brad obviously knows this. I'd be stunned if he didn't, 'cos it's security 101 stuff.)

All this is true no matter what security system you are discussing. All security systems for commodity OSes are really there to keep out mass attacks and attacks by the non-ingenious. Thanksfully, nearly all attacks are of these classes.

Walsh: Introducing the SELinux Sandbox

Posted May 29, 2009 1:14 UTC (Fri) by hozelda (guest, #19341) [Link] (1 responses)

nix, I think you are basically correct, but an attack on a FOSS system is complicated by the fact that users can take active steps at any time to help thwart attacks. These users have a lot more information at their fingertips than those who don't have source code nor an ability to controllably change their system around whenever they feel it is necessary.

It's ridiculous how vulnerable you are when you depend fundamentally on information others are keeping secret from you.

Walsh: Introducing the SELinux Sandbox

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

Yes. Hell, even if they don't know the attack class and can recompile
everything, they can simply randomly perturb their system
(function-neutral changes to ABI, say) or change their architecture:
security through obscurity may be an ugly hack but the number of people
launching attacks on old MIPS boxes is minimal :)

Walsh: Introducing the SELinux Sandbox

Posted May 29, 2009 17:25 UTC (Fri) by Arach (guest, #58847) [Link]

> Brad and PaXTeam assert (although they will doubtless deny this as part
> of the charmless dance of evasion they both employ whenever their
> reasoning is faulty) that this renders all such security systems
> worthless.

Excuse me, but I can't find where one of them asserts anything like that. Would you be so kind to provide a relevant quote or a link, please?