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