| 
 Home
Download
Test Patches
Features
Forums
Mailing List
Wiki
CVS
Links
Mirrors
Donations
Sponsors
LSM
Papers
Contact Us
|
Lightbulbs are going off
Our arguments against LSM haven't changed since we made them public over a year ago, but now it seems that the very people (hi Chris Wright) who were pushing LSM on us are now suddenly completely against it (and are even using our exact arguments as reasons why; I guess things like rootkits just suddenly started bothering them). Crispin Cowan got what he wanted out of the deal: his security module used the mainline kernel's security framework, thus making it a nice (by nice, I mean easily exploitable) tool for Novell to buy out.
Conveniently, SELinux has made its way into the kernel, and all other security systems will be pushed out. Conveniently, many companies have their fingers in the SELinux pie and surely will be making money off "service" and "support" (hi Tresys, nice business model you have) for a system that is unusable for the market it's being pushed upon. Everyone please repeat the SELinux mantra: information flow graphs are important! SELinux is a proven model! What? Kernel exploits? Oh, that's right, SELinux conveniently leaves kernel exploits out of their "threat model," and no one questions it. By pure coincidence, ignoring this fact allows them to continue to propagate the myth that SELinux's information flow graphs are proven, and that SELinux provides a guarantee of security.
Connect the dots folks, this LSM debacle has had nothing to do with technical merit (since these arguments haven't changed at all) and has everything to do with the self-interest and profit of several individuals and companies.
|
|
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.
|
|
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.
|
|
Comments from other projects
|
|
 |
