Walsh: Introducing the SELinux Sandbox

Posted May 28, 2009 6:44 UTC (Thu) by nix (subscriber, #2304)
In reply to: Walsh: Introducing the SELinux Sandbox by spender
Parent article: Walsh: Introducing the SELinux Sandbox

So... let me get this straight. To you this entire argument isn't about
whether SELinux is an effective sandbox (it is, modulo kernel bugs, and
local attackers might be impeded somewhat by having to do all their work
through a pipe that getting local access might be harder than before: your
requirement for total kernel security is ridiculous on its face and
counter to the security philosophy that you espouse elsewhere in the *same
message*, of strength in depth). It isn't about how much ease of use it
brings over plain unadorned SELinux, if any (which is what the article was
actually about).

It's about the *phrasing of the release announcement*?! Do you seriously
think that so many people are going to read it and use the sandbox code
(as opposed to, say, picking up F11 and getting it by default without
reading that announcement at all) that what they think after reading the
announcement will make *any* difference to security?

Do you seriously think, after twenty-plus years of viruses, that *anyone*
believes *any* vendor's claim that *anything* is totally secure? (In any
case, that assertion was not made in this case: 'more secure' than an
SELinux that guards only system daemons it surely is). The public are not
idiots and aren't going to be reading this release note in enough numbers
to affect security in any case.

You have a nerve talking about straw men when your entire argument is
based on a misreading and you contradict yourself in a single post.

to post comments

Walsh: Introducing the SELinux Sandbox

Posted May 28, 2009 12:16 UTC (Thu) by spender (guest, #23067) [Link] (3 responses)

Yes, the argument is mostly about phrasing, because despite your inability to accept it, it does matter. It's not just about this single announcement, but rather about *every* announcement, discussion, or documentation about SELinux. You can see how effective the propaganda is when you look at how SELinux is discussed by users. Look at how often words like "proven" or "can only" are thrown around when talking about SELinux -- you yourself used "proven" multiple times. Do you use these same kinds of phrases when talking about NX or ASLR? It's quite silly to say a technology is "proven" or that it makes sure a process "can only" do something, modulo [list of things that bypass it].

If people aren't buying the propaganda, as you claim, then why is SELinux being offered as a replacement for air gap among people who don't know any better. Either no such users of the air gap replacement exist (which reality says is false), or they do exist (they do). Are you claiming that putting unclassified data on the same physical machine as top secret data is a good idea and a person doing so can be "without fear of information contamination"? Those aren't my words, they're Red Hat's -- and whether you want to believe it or not, people *are* buying it. I'd really like to hear your answer to this question, actually.

Nowhere did I make a requirement for "total kernel security" -- I simply made the point that you can't claim guarantees or "proven models" unless there actually does exist some guarantee or proof, which in this case there does not and cannot.

You failing at reading comprehension and putting words into my mouth does not a contradiction make.

-Brad

I'll give you credit, but how much?

Posted May 28, 2009 17:39 UTC (Thu) by hozelda (guest, #19341) [Link] (1 responses)

I know few real details of the Linux kernel or of SELinux, but what Brad criticizes in these comments, at least on the surface, seems completely correct.

To be precise, if SELinux is ever changed or if any part of what SELinux depends on working properly ever changes in behavior, then one has to redo the "proof". Maybe this proof redo will be easy for most changes that happen in practice, but maybe not.

In any case, what is the code that must be audited and proven correct for SELinux to work as intended? That would have to be identified and locked down so that any weaknesses could not be introduced by changing anything else. [Eg, if hacking some part of the kernel with the sole intention to compromise the system is done, then that should not affect the "SELinux promise" unless that part being hacked was included as being needed to be locked down.]

I suspect there are too many assumptions being taken by those that would say SELinux is bulletproof. Software is not hardware. Has the hardware and the hardware creation processes and tools been audited?

Now, in practice, it would be a long list to document all the (eg, hardware) assumptions needed for SELinux to work as well as, eg, we might believe is the alternative of isolating data on different machines "not connected" with each other.

Then again, have we proven how many vendors sell a solution where they prove all of their product's requisites? There is an awfully lot of physics that must be documented or at least the assumptions stated. And this says nothing about physics we can't know we don't know about. Truly I don't believe anything is "proven" unless you talk within a limited context. We don't need a degree in philosophy to keep finding potential shortcomings with any system claimed to be perfect.

In short, I think the assumptions should be stated, if not on the glossy brochures main pages, at least on a little comment somewhere. Then again, most people that would identify some of these issues would challenge any vendor claiming some system was provably perfect, in order to weed out the actual assumptions being made. Brad might be going too far and might be playing devil's advocate ad infinitum, perhaps picking on Linux or FOSS because he has allegiances elsewhere. [?]

From what I have heard, the vast majority of the US government or likely virtually 100.0% [note an implied margin or error] of all other institutions out there do not have such high requirements. In these case, a risk analysis would probably reveal weaker links than an SELinux. In these cases, some of the hidden assumptions might be known or else taken for granted no matter the vendor.

Now, let's move the spotlight to Brad completely to wrap up this comment. Does Brad know of any provably secure system, for example? Has his best choice (not counting SELinux) stated their assumptions fully? Could I get access to these assumptions and the proofs? [eg, to the full blueprints for how such a system could ever possibly behave (given its assumptions) with a full analysis of what was believed to be the pertinent physics? And some analysis of what would happen if any of the assumptions were found not to hold?]

Are we all putting things into perspective AND trying to be honest about assumptions, or is perhaps each side failing? When you talk proving security, only the most open of systems could ever honestly attempt to engage in that conversation. Does a system that is really open exist (at hardware, software,... all levels)? Does it even make sense to speak of proofs when referring to physical systems?

I'll give you credit, but how much?

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

I'll try to answer all the questions you asked in your post.

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

Walsh: Introducing the SELinux Sandbox

Posted May 28, 2009 18:01 UTC (Thu) by hozelda (guest, #19341) [Link]

>> If people aren't buying the propaganda, as you claim, then why is SELinux being offered as a replacement for air gap among people who don't know any better.

Who do you believe doesn't know better that was addressed by Red Hat? And since when has the air been that good at preventing information from propagating?

Most customers fairly serious about security who would take any vendor's word on perfection would seek out certifications "just to be safe." [And note that many customers have claimed to value security yet have taken the word of vendors that keep their systems closed source!]

And even with certifications, look at what can happen: http://cryptome.org/ed-curry.htm . Customers may "want" security, but most apparently speak a different language when it comes to making purchases so are willing to trust vendors and look the other way.

Anyway, for the sake of approaching intellectual honesty, the SELinux vendors (and everyone) should consider telling the whole story [and closed source vendors should stop trying to push their wares on security conscience buyers since they aren't even willing to meet the basics of transparency and peer review].