Walsh: Introducing the SELinux Sandbox

As for what code needs to be audited for SELinux to work as it's claimed to, that's not really useful in reality, as:
1) Development on the kernel would have to stop (or the code would have to be audited constantly, which isn't cheap)
2) Auditors aren't perfect
3) The problem is architectural; as James said further down on this page (the first time I've seen an admission like this from anyone at Red Hat, but my memory may be wrong): "SELinux cannot be expected to protect against kernel vulnerabilities, because it is part of the kernel."

Indeed, most vendors exaggerate the abilities of their products. The most egregious example I can think of right now is anti-virus software; but being as the parent article is about SELinux, I talked about SELinux (with some mention of Xen and VMWare as well).

Regarding "Brad might be [...] perhaps picking on Linux or FOSS because he has allegiances elsewhere. [?]", as I (and the PaX team too for that matter) have spent just about every day for the past 8 years working on free software to improve Linux security, that's a little insulting -- but I imagine you weren't aware of that (no problem).

I don't know of any provably secure OS -- surely it wouldn't be anything like the OSes people actually use if one did exist. It's not really useful to entertain this idea; what's useful is thinking about how to improve things in ways that don't add complexity or burden on a user. Achieving higher levels of security is useful, raising the cost of developing an exploit by making exploitation techniques more difficult and complex is useful.

It's especially important now with the 2.6 development model (moreso than it was with the 2.4 series of kernels) that greater considerations be made for security in the kernel itself. I've mentioned this on previous articles, but it goes without saying that when you have a ~80MB patch of new code/changed code/removed code every 3 months, there are a lot of vulnerabilities being introduced. It's been made clear by the kernel developers that there's no intention of changing the development model, so instead of just accepting the problem and continuing in the "fix vulnerabilities that get reported to us, release a 'stable' update once a week" mindset, something more can be done.

You mentioned "weaker links than an SELinux" -- I don't know if there was a typo involved there, but I don't want to give the impression that SELinux is a weak link. Considering the length of time it's been around, its code quality has been better than most, with only a handful of vulnerabilities reported (though some were silently fixed, like the remote DoS from 2005 (I think) that I mentioned several months back. It was discussed among the vendors on a private list, noting that attacks had been seen in the wild, but still no CVE or announcement was released -- I assume because at the time the attacks had been discovered, the bug had already been fixed). Restricting what files, etc a process can access is useful too as not all vulnerabilities involve memory corruption/arbitrary code execution. In that respect, it's a good complement to the NX+ASLR protections already in place. But again, it's important to realize the limitations of the technologies so that levels of risk can be properly evaluated.

-Brad

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.]

"it seems a bad idea to think that any specific part of the kernel is able to protect the kernel." -- I just gave you an example that you agreed makes the kernel more secure. Do you need more examples? I listed them in another post. Why's it such a bad idea to make classes of vulnerabilities unexploitable and thus prevent someone from being able to take advantage of an applicable vulnerability for the purpose of arbitrary code execution in the kernel?

You said that it's a bad idea to think that the kernel can protect itself, but then you go on to say that SELinux is a good way of protecting the kernel (or at least, better than fixing a couple bugs). I agree -- it's better than fixing a couple bugs, but it's the wrong approach for protecting the kernel. And like it or not, a lot of what SELinux bothers itself with is an attempt (either directly or indirectly) to protect the kernel. There's no reason really to restrict some obscure system call that an application doesn't use in any of its code-paths unless you're assuming the possibility of arbitrary code execution. Even then, there's not much point in restricting the obscure system call (there are plenty more useful ones for the attacker that aren't restricted) unless you're trying to reduce the attack surface of the kernel.

It should be clear that using SELinux to try to protect the kernel isn't very successful, especially in the face of remote exploits (as noted earlier). It calls into question the usefulness of the additional complexity required for the vain attempt at keeping attackers either from doing things they don't want to do that they can do in other ways, or from exploiting the kernel. It seems to me that it makes more sense to make classes of vulnerabilities unexploitable. It adds no additional complexity or burden on the user and has demonstrated itself to be more useful against real attacks. Take for instance, as I mentioned in another post, about what's been done in terms of hardening userland applications invisibly -- these kinds of changes (when implemented properly at least) are incredibly useful. In fact, the addition of a protection to SELinux (which really sticks out from its other features, and was contributed by a 3rd party) which is essentially PaX's MPROTECT feature, is actually one of its most useful protections. What's needed is more of that reality-based security, not academic pie-in-the-sky solutions. The former's been working well for years, the latter is still struggling for over a decade to be relevant.

-Brad

Just so that's clear.