In a brief follow up to the earlier pluggable security discussion, Thomas Fricaccia reflected on the implications for the various security frameworks, "I noticed James Morris' proposal to eliminate the LSM in favor of ordaining SELinux as THE security framework forever and amen, followed by the definitive decision by Linus that LSM would remain." He then commented on a recent merged patch preventing the loading of security modules into a running kernel, "but then I noticed that, while the LSM would remain in existence, it was being closed to out-of-tree security frameworks. Yikes! Since then, I've been following the rush to put SMACK, TOMOYO and AppArmor 'in-tree'." Linus Torvalds replied:

"Yeah, it did come up. Andrew, when he sent it on to me, said that the SuSE people were ok with it (AppArmor), but I'm with you - I applied it, but I'm also perfectly willing to unapply it if there actually are valid out-of-tree users that people push for not merging. So Í don't think this is settled in any way - please keep discussing, and bringing it up. I'm definitely not in the camp that thinks that LSM needs to be 'controlled', but on the other hand, I'm also not going to undo that commit unless there are good real arguments for undoing it (not just theoretical ones).

"For example, I do kind of see the point that a 'real' security model might want to be compiled-in, and not something you override from a module. Of course, I'm personally trying to not use any modules at all, so I'm just odd and contrary, so whatever.. Real usage scenarios with LSM modules, please speak up!"

"I think the decision to merge Smack is something that needs to be considered in the wider context of overall security architecture," suggested James Morris following Andrew Morton's recent comment that he plans to merge the functionality in the upcoming 2.6.24 kernel. While James had no complaints about Smack itself, he expressed concerns regarding the pluggable nature of LSM, which is used by Smack, cautioning, "if LSM remains, security will never be a first class citizen of the kernel," adding, "on a broader scale, we'll miss the potential of Linux having a coherent, semantically strong security architecture." He noted that he'd rather see SELinux as the sole Linux security framework, "merging Smack, however, would lock the kernel into the LSM API. Presently, as SELinux is the only in-tree user, LSM can still be removed."

Linus Torvalds firmly stated, "LSM stays in. No ifs, buts, maybes or anything else." He explained, "you security people are insane. I'm tired of this 'only my version is correct' crap. The whole and only point of LSM was to get away from that." Linus continued, "I guess I have to merge AppArmor and SMACK just to get this *disease* off the table. You're acting like a string theorist, claiming that t here is no other viable theory out there. Stop it. It's been going on for too damn long." Stephen Smalley responded, "you argued against pluggable schedulers, right? Why is security different?" Linus explained:

"Schedulers can be objectively tested. There's this thing called 'performance', that can generally be quantified on a load basis.

"Yes, you can have crazy ideas in both schedulers and security. Yes, you can simplify both for a particular load. Yes, you can make mistakes in both. But the *discussion* on security seems to never get down to real numbers. So the difference between them is simple: one is 'hard science'. The other one is 'people wanking around with their opinions'."

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.