|| ||James Morris <jmorris-AT-redhat.com>|
|| ||Crispin Cowan <crispin-AT-novell.com>|
|| ||Re: New stacker performance results|
|| ||Wed, 25 May 2005 20:03:52 -0400 (EDT)|
|| ||Stephen Smalley <sds-AT-tycho.nsa.gov>,
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
Alternatively, consider submitting your module upstream.
(Of course not speaking for Red Hat, as usual).
to post comments)