Home > LSM
Why doesn't grsecurity use LSM?
As Linux 2.6 approached, I observed an increasing number of questions regarding grsecurity's usage of LSM. My short answer has always been "because we can't". The reason for this is multifaceted; there are also reasons why I simply do not like LSM and believe that its existence will actually harm security as a whole. I've discussed this issue with several other security projects that share the same beliefs. When they post their opinions, I will link to them here. The rest of this page will explain my stance on LSM.
Why grsecurity cannot use LSM
- It seems as though LSM has been designed for the few systems that support it currently; it seems as if there has been little or no research done to determine what kinds of hooks all security systems for Linux currently need and what the next generation of security systems will require.
- LSM involves only Access Control. grsecurity performs many other functions than just Access Control, so these features can not operate under LSM.
- Because some features of grsecurity are impossible to integrate into LSM's framework, kernel patching would still be required. Thus, the usability benefit for end-users is negated.
- The amount of work required to port to LSM is very large, and could be spent on solving real problems rather than porting pre-existing code to a framework that is likely to change (as they realize it is unsuitable for most purposes)
- The amount of work I spend porting to new kernel releases is minimal. I doubt that the amount of work required to port to new kernels will ever surpass the amount of work required to port to LSM once. Thus, the benefit of LSM from a developer standpoint is negated as well.
Why LSM will harm the security of all Linux systems
- Though LSM can be disabled in the vanilla kernel to allow the system to work functionally as it did in 2.4, all linux distributions will most likely be enabling it in their kernels. The mere existence of a security framework is not going to urge more users to use Trusted OS components in their kernels.
- Because LSM is compiled and enabled in the kernel, its symbols are exported. Thus, every rootkit and backdoor writer will have every hook he ever wanted in the kernel. This will allow for a new generation of sophisticated backdoors and rootkits that will be nearly impossible to detect.
- LSM still does not support stacking of security modules, or in fact support security modules currently at all! Today, grsecurity is compatible with all other LSMs -- if grsecurity were made to use the LSM framework, users would have to decide between it and other frameworks distros force on their users (Fedora/RHEL -> SELinux, Ubuntu/SuSE -> AppArmor). This removal of choice is detrimental to users' security.
Why I personally dislike LSM
- I believe LSM entered the kernel, not because of its technical merit or usefulness, but because of apathy from people involved in kernel development who are able to make a difference in such decisions.
- I do not appreciate that the original intention of those backing LSM was to allow for the existence of proprietary security modules that used the kernel's GPL'd interfaces. This is no longer an issue, however I believe that such an intention may have affected the design of LSM greatly to allow for such a thing, instead of designing LSM for actual usefulness.
- It seems to be the case now that LSM was simply a ploy to get SELinux into the kernel. Anyone wishing to develop their own security system are now being told to implement it within the SELinux framework, not the LSM framework. With this kind of attitude, it will be impossible to have significant changes made to the LSM framework. UPDATE (Mid 2009): New security modules are finally being allowed mainline, so hopefully the push from certain individuals to make SELinux the 'one true security model' for Linux is over.
