* James Morris (jmorris@private) wrote: > 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. Ahh, the irony ;-) Sounds like reiser4, in fact didn't they recommend being the VFS (/me runs). > 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. This is actually quite important point that James makes. I disagree that out of tree code counts for nothing (afterall even SELinux started as out of tree code ;-), but it has a lot less to say on in tree code/design/etc. Point being, you can't expect anything from the core if you aren't giving anything back. And, in nearly all cases, the process of submitting code improves the code. > 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. Be specific, it will help make your point. As it is, it sounds quite handwavy. Of course, it's not true that the LSM framework is not being used. What's true is that it's a thin layer that provides only the upcall mechanism for SELinux (from your perspective). But then, that's all it's supposed to do, be an upcall mechanism. > It's dead code, an unecesary abstraction layer between its one real user, > SELinux, and the core kernel. Hey, you keep forgetting about capabilities... > 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. Have to agree. > 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. Developing infrastructure for real users makes sense. As you mention, there are other security models besides SELinux that helped shape LSM. What's sad is the lack of those in mainline. > 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. What are these burdens and limitations you keep alluding to? They should be addressed as technical issues.
This archive was generated by hypermail 2.1.3 : Wed May 25 2005 - 22:29:45 PDT