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

-