"I think people are placing too much blame on valgrind. valgrind doesn't tell you 'Delete this line of code.' It says 'You are using uninitialized memory here.' The correct fix is to initialize the memory, not delete the line of code. It's not about trusting or not trusting the tool; it's about responding correctly."
A thread on the OpenBSD-misc mailing list compared the security of SELinux in the 2.6 Linux kernel to what's available in OpenBSD. The general opinion was that SELinux and its policy language are too complex, leading Damien Miller to note, "every medium to large Linux deployment that I am aware off has switched SELinux off. Once you stray from the default configurations that the system distributors ship with, the default policies no longer work and things start to break." Ted Unangst summarized, "the problem with security by policy is that the policy is always wrong."
Darrin Chandler suggested, "security should not be grafted on, it should be integrated into the main development process. I'm sure the patch maintainers are doing their best, but this doesn't change the fundamental flaw in the process. It's not a flaw of their making, it's inherent in the situation. But it's still a flaw." It was pointed out again that SELinux is part of the 2.6 kernel via LSM, to which Jason Dixon noted, "SELinux is a button. Buttons are easy to turn off. Darrin went on to say, "compare that to a complete operating system (OpenBSD) where security is part of code quality, and part of the normal mainline development." The security features in OpenBSD that were then discussed included propolice stack protection, random library mappings, proactive privilege separation, W^X, and systrace.
