"In a nutshell, there is no safe way to unload an LSM. The modular interface is thus unecessary and broken infrastructure. It is used only by out-of-tree modules, which are often binary-only, illegal, abusive of the API and dangerous, e.g. silently re-vectoring SELinux," explained James Morris in an October 17'th commit message converting LSM to be a static interface. Andreas Gruenbacher countered, "LSM can be abused ... so what, this doesn't mean the interface is bad. Non-LSM loadable modules have been known to do lots of bad things, and yet nobody made them non-loadable either (yet)." Linus Torvalds explained that he was willing to unmerge the commit if a valid use for unloadable modules was demonstrated, "I repeat: we can undo that commit, but I will damn well not care one whit about yet another pointless security model flamewar."

Jan Engelhardt pointed to his multiadm security framework which provides multiple "root" users each with unique UIDs as an example of an LSM that benefits from supporting loading and unloading modules. "The use case is so that profs (taking the role of sub-admins), can operate on student's data/processes/etc. (quite often needed), but without having the full root privileges," Jan explained, adding, "this LSM basically grants extra rights unlike most other LSMs, which is why modprobe makes much more sense here.(It also does not have to do any security labelling that would require it to be loaded at boot time already.)" James acknowledged, "based on Linus' criteria, this appears to be a case for reverting the static LSM patch."

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'."