That's not what I'm saying. Also, you made the unsubstantiated assumption that putting "some focus on improving the security of the kernel" means "security bug fixes" and then attributed that assumption to me so that you could dismiss it (straw man).
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.
There's no better demonstration in my mind of the importance of improving the kernel's security than the fact that it was possible to disable SELinux remotely with a single 4-byte write. A proper response to the exploit should have been to look at the techniques used (which surely will be duplicated in future exploits as the code is public) and see what could be done to prevent them. 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.
Maybe I haven't looked hard enough, but I can't find any article from a vendor promoting SELinux that discusses the reality of what it can do. I just did a random google search for SELinux MLS and came up with: http://www.centos.org/docs/5/html/Deployment_Guide-en-US/...
It's a document written by Red Hat talking about how SELinux can be used to keep untrusted users with access to unclassified information from ever being able to access top secret information. Given the above mentioned remote root exploit, using SELinux for such a purpose is both frightening and irresponsible. I'm not exaggerating at all here; here's an entire paragraph straight out of the article:
"Some organizations go as far as to purchase dedicated systems for each security level. This is often prohibitively expensive, however. A mechanism is required to enable users at different security levels to access systems simultaneously, without fear of information contamination."
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.
As a good contrast to the "claim it's provably secure and that x can never read/write y" approach to security features, I recently spotted Kees Cook's blog at: http://www.outflux.net/blog/archives/2009/05/14/nx-emulat...
where he was talking about adding exec-shield to Ubuntu, while calling it NX emulation in the case where hardware NX support wasn't present. I pointed out to him that this was misleading, and gave several examples of how it provides substantially weaker protection than a hardware NX implementation. He quickly verified my claims, and furthermore found what is likely another vulnerability in exec-shield which allowed for executable heaps (though I haven't verified it myself). After this, he made the responsible decision to call it "partial NX emulation" instead.
A reasonable view like that is what's needed in Red Hat's article above. Instead of offering software as a replacement for air-gap and suggesting there's "no fear of information contamination," the caveats of the approach should be mentioned (any at all, there are none whatsoever discussed in that article). You'll save the cost of hardware and maintenance of a machine, at the potential cost of the information residing on the machine.
To wrap this up, back to what I mentioned earlier about improving the security of the kernel and how this doesn't have to do with fixing individual bugs. If you look at what's been done in terms of preventing exploitation of security vulnerabilities in userland (NX, ASLR, PIE, RELRO, SSP, etc) similar things can be done for the kernel. Kernel hackers don't have to stop all development, the changes are transparent to the user, and the protections apply to both current vulnerabilities and vulnerabilities introduced in the future.
Some of PaX's features are already tackling these problems, and continue to improve (in fact, an upcoming change to PaX will defeat the technique used by sgrakkyu's remote root SELinux-disabling exploit to easily switch from interrupt context to process context). Among the already existing features (in addition to security-improving changes for which no configurable option exists) are KERNEXEC, MEMORY_UDEREF, MEMORY_SANITIZE, REFCOUNT, RANDKSTACK, and USERCOPY.