Yes, I think Crispin has succinctly summed it up:  irrevocably closing

the LSM prevents commercial customers from using security modules other

than that provided by their Linux distributor.  As Sarbanes-Oxley and

other regulatory laws require these customers to use "standard

kernels", the result is a rather dreary form of vendor lock-in, where the

security framework is coupled to the distribution.
Though it would require a somewhat undesirable complexity of CONFIG_

flags, it should be possible to construct flexibility enough for everyone

to get what he wants.  For example, it should be possible to configure

kernels with a single security framework hard-linked, AND it should

also be possible to configure kernels such that the default security

framework could be completely replaced at boot time by another, be it

out-of-tree module, or other.
I agree entirely that preserving this form of freedom for the end user

makes Linux a much stronger technology than not.  For one thing, the

consequences of closing LSM are fairly certain to irritate enterprise

commercial customers, which is probably a sign that the technology has

taken a wrong turn.
Tommy F.
-

On Sun, 21 Oct 2007 19:24:42 -0700
Crispin at least is providing genuine discussion points. Sarbox has

nothing to say on "using vendor linux kernels".
-

I agree that SarBox is not really the issue here. Partially related is

enterprise rules about what kernels one is allowed to load. More

generally, this change forces users who want to use a different LSM than

their vendor provides to recompile their kernel, where they did not have

to recompile before. It forces LSM module developers who want to modify

their LSM to reboot, where they didn't necessarily have to reboot before.
That is not a catastrophe, it is just tedious. It does not kill baby

seals, and it does not make Linux utterly useless. OTOH, I think it is

strictly negative: it takes away user choice in 2 dimensions, and adds

zero value. So apply it if you must to bake the kernel developer's lives

easier, but it really is a net loss in Linux kernel capability.
Crispin
--

Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/

	       Itanium. Vista. GPLv3. Complexity at work
-

The moment they load a module from a third party they usually hit support
Frankly I don't care about apparmor, I don't see it as a serious project.

Smack is kind of neat but looks like a nicer way to specify selinux rules.
What I do care about is that at some point something is going to appear

which is based on all the same good practice and experience and forty

years of research that leads towards SELinux, and which is much better. At

that point there will be a changeover phase and the LSM is exactly what

is needed for this.
The fact it allows people to play with toy security systems, propose new

ones like SMACK, and do research and PhD work on Linux into security is a

convenient and very good side effect.
For that reason I think keeping LSM is the right thing to do.
Alan

-

Wait, we aren't talking about dropping LSM at all, just the "LSM is a

module" option.  That's it.  And by making LSM not a module, we can then

go on to fix some of the reported speed issues that are present with the

LSM option enabled right now.
thanks,
greg k-h

-

Any "customer" using a security model other than provided by their Linux

distributor instantly voided all support from that distro by doing that.
So, since the support is gone, they can easily build their own kernels,

with their own LSM interfaces, and get the exact same lack of support :)
And, what are these "other LSM modules" you speak of that people rely on
Wait, what?
Since when does Sarbanes-Oxley decree that a company must use a

"standard kernel"?  And just exactly what defines such "standard

kernel"?  Can you point out where in that bill it requires such a thing?
Totally confused,
greg k-h

-

Simple, these days Sarbanes-Oxley is the default argument behind anything being

pushed down your throat in a company.
Gr{oetje,eeting}s,
						Geert
--

Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But

when I'm talking to journalists I just say "programmer" or something like that.

							    -- Linus Torvalds

-

Running a vendor kernel has the advantage of reusing all the QA work

that has gone into that kernel.  It is very different from running

2.6.24-rc1 (or 2.6.22.x).  Hence projects like centos: you don't get any

support, but the likelihood of actually requiring support is lower than

running some random kernel.
[but I agree that someone who has somehow determined that they need a

specific LSM will probably have determined that they need vendor support

as well]
--

error compiling committee.c: too many arguments to function
-

You can also get the QA work by building your own kernel from vendor

kernel sources.
E.g. the Debian distribution ships a package linux-source-2.6.18 that

contains a linux-source-2.6.18.tar.bz2 with the patched 2.6.18 kernel 
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
-