On Wed, 25 May 2005, Crispin Cowan wrote: > As a supplier of a different security module than SELinux, I naturally > vehemently object to the suggestion of "just remove LSM and use SELinux > instead." That would be a huge step backwards. Linux is all about > choice, and LSM effectively provides for that choice. In the years since LSM was included in the mainline kernel, SELinux has been the only significant module implemented and also included in the mainline kernel. So we have a generalized framework for one user, SELinux, which itself is a generalized framework. Note: out of tree kernel code does not count for anything. It's not really part of the Linux kernel. Mainline maintainers don't care about it and should not be expected to. If you want them to care, for people to fix bugs in it for free, and for more people to use it, then submit the module for upstream inclusion. It seems rather strange that you haven't. SELinux is limited by the LSM framework (which is sometimes good -- because it forces thinking in the general case -- but not always), and the LSM framework itself is effectively not being used in the mainline kernel. It's dead code, an unecesary abstraction layer between its one real user, SELinux, and the core kernel. Another isssue is that LSM is IMHO being increasingly mis-used as a way to try and get rather arbitrary security code into the kernel, without due justification, just because it has a few hooks in the right place, or because S stands for security, or something. This is an unfortunate side-effect of developing an infrastructure with such weak semantics, and the initial grumblings from the core kernel developers on this issue appear to have been on the money. Developing infrastructure for imaginary users is always the wrong thing to do. Historically, there were several potentially viable enhanced access control models which may have become mainline LSMs, such as DTE, but SELinux has supplanted all of them. As for choice, your LSM module is not in the mainline kernel, so only users of your particular kernel really get that choice. Why does LSM then need to be in the upstream kernel? Why not just keep it in yours, to support your out of tree security module. Why impose the burdens and limitations of LSM on the upstream kernel, which effectively doesn't use it? If you want LSM, feel free to keep it in your kernel and maintain it yourself. Alternatively, consider submitting your module upstream. - James -- James Morris <jmorris@private> (Of course not speaking for Red Hat, as usual).
This archive was generated by hypermail 2.1.3 : Wed May 25 2005 - 17:04:28 PDT