I'll give you credit, but how much?

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

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?

to post comments

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