Some well-respected contributors have taken exception my amplification

of Crispin Cowan's point about the patch that closes LSM.
I extended this point by observing that regulatory laws make it difficult

for enterprise customers to compile their own kernels, mentioning one

of the more invasive statutes, Sarbanes-Oxley.
I was actually talking about the *effects* of regulatory law, rather

than the wording in the text of the statutes.  The misunderstanding

could be partially my fault, as my exact words were 
   As Sarbanes-Oxley and other regulatory laws require these

   customers to use "standard kernels" ....
which may not have been as unambiguously clear as I intended.
But as long as we're here, let me elaborate on the point I tried to make.
SOX and other laws require enterprise customers to keep specified

controls on their internal processing procedures, and keep documentation

that can be audited to prove compliance.  The auditing requirements

are extensive and detailed, and certainly include the kernel of an

operating system used to process business and/or financial transactions.
It is within this framework that enterprise customers conclude something

like (and this is vernacular, not the language within the statutes) "if

we use any kernel other than that supplied by our distributor, the

SOX auditing paperwork will be a nightmare."  (I've actually heard

statements similar to this, and so believe that it is an accurate

portrayal of the perception of the effects of regulatory law.  I'm not

a lawyer.)
As I said at the beginning, I meant to amplify Crispin's observation

that enterprise customers are reluctant to compile their own kernels

with the additional observation that the complexities of regulatory

law create obstacles that are significant contributors to that reluctance.
I'll not belabor the unfortunate non sequitur further.  You can find

plenty of documentation of auditing requirements with by Googling

combinations of "Sarbanes-Oxley," "operating system i...
[ message continues ]

What do technical and regulatory differences have "driver/LSM module" that

is build-in and one that is modular?

It seems to me silly to find difference.  A kernel with a new kernel module

is a new kernel.
ciao

	cate

-

*I* understand that, from a security and logic integrity point of view,

there is not much difference between a rebuilt-from-source kernel, and a

standard kernel from the distro with a new module loaded.
However, there is a big difference for other people, depending on their

circumstances.
    * Some people live in organizations where the stock kernel is

      required, even if you are allowed to load modules. That may not

      make sense to you, but that doesn't change the rule.

    * Some people are not comfortable building kernels from source. It

      doesn't matter how easy *you* think it is, it is a significant

      barrier to entry for a lot of people. Especially if their day job

      is systems or security administration, and not kernel hacking.
Think of it like device drivers: Linux would be an enterprise failure if

you had to re-compile the kernel from source every time you added a new

kind of device and device driver.
Crispin
--

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

	       Itanium. Vista. GPLv3. Complexity at work
-

That's why I wrote a whole book about how to do just that.  And it's

free, print it out and give it to all your friends!

	www.kroah.com/lkn/
thanks,
greg k-h

-

[read also the very last commentary: don't take to seriously my

arguments]
ok, but why simplifying life of company with such silly rule?

Are not the same people that required commercial UNIX kernel?

So don't worry about internal company rules.  In one year a lot

of things changes.

Anyway it is a good motivation to delay the conversion, if there

are really so many external LSM modules used in production environment.
Configuring a new kernel is not "kernel hacking" and IIRC is considered

in the very first level of LPI.
Anyway where you will find the new module?  It should be very specific

on the actual kernel installed.  I find few differences to distribute

a module or a kernel.  Distributions have/had a lot of kernels

(versions, SMP, processor specific, vserver, xen, readhat, clusteres,

...), so why not distribute a new kernel?
 > Think of it like device drivers: Linux would be an enterprise

 > failure if you had to re-compile the kernel from source every

 > time you added a new kind of device and device driver.
This is a frequent argument, but I don't believe it ;-)

I see more time this argument that new devices on an enterprise.

Which is a good point to have modules.  Is it still a good point

to have LSM modules?  And to obey the "Sarbanes-Oxley"
Don't take me wrong, the above commentaries are not so serious,

and my point was not about modules, but why "Sarbanes-Oxley"

tell us that new modules are simpler then new kernel.
I like kernel without modules, so I want to understand all motivations

why people need modules (and this thread showed me other (non-classical)

reasons).  I know that the modules are necessary in most situation, but

I like to see if some reasons can be solved in other ways, so to

simplify also the life of "build-in" peoples.
ciao

	cate

-

But that is completly true _today_ and is the way that the "enterprise"
I agree, that is why customers do not load other random security modules

in their kernel today, and why they will not do so tomorrow.  So,

because of that, this whole point about compliance with regulatory law

seems kind of moot :)
Again, LSM isn't going away at all, this is just one config option for

allowing LSM to work as a module that is changing.  If a customer

demands that this feature come back, I'm sure that the big distros will

be the first to push for it.  But currently, given that there are no

known external LSMs being used by customers demanding support, I don't

see what the big issue here really is.
thanks,
greg k-h

-

I have an out of tree module to do per-port (tcp/udp) bind permissions,

it works fine with the "capability" module as secondary and I can load

or unload both of them at any time... this recent change completely

breaks that. (I had to #include dummy.c though).
Why should I now need to:

1. reboot every time I change the code when I could just reload modules before?

2. put it into my kernel source tree to use it?
--

Simon Arlott

-

That "random" module could be a module supplied by a vendor other than

the distro supplier, such as a security vendor. It could be a research

prototype that the user wants to try out on their enterprise-supported

kernel. It could even be an in-house developed module that a local site

wants to run on his larger organization's blessed kernel.
So far from "random", these modules are motivated by circumstances

radically different than yours. In particular, rebuilding a kernel for

you (GregKH, many LKML developers) is a casual thing to be done before

breakfast, but is a scary obstacle to many others. It is an obstacle to

people who are skilled at computers but deliberately *not* kernel

developers (the whole world does not need to be a Linux kernel

developer) and it is an obstacle to large enterprise admins who have

I think the specific stuff about regulatory compliance is tangential.

SarBox and friends don't specify Linux kernel versions, they are

incredibly vague and subject to interpretation. But they are part of

what drive organizations to have self-imposed rules about only running

blessed kernel versions.
Suffice it to say that there are a variety of reasons why someone either

cannot re-compile a kernel, or just does not want to recompile a kernel.

This change to LSM removes their choice to use modules others than those

As I said, it is a medium issue, not a big one, which is why I didn't

speak out before.
I am opposed to this change because I see zero benefit to it, and a lot

of down-side in loss of user choice.
Because that is what this does: it does not help the kernel get better.

It *definitely* does not help the kernel become more secure. It mostly

just removes user's choice, by making it difficult to do things that

some people don't approve of.
As I've said, it doesn't hurt AppArmor, because 3 major distros ship it.

But it will hurt user choice and innovation, by making anything not

shipped by a distro more difficult to access.
There is some performance gains to be ...
[ message continues ]

one reason to not be willing to rebuild the kernel is that they may rely

on a module from a different third party that is shipped/tested for the

specific pre-compiled kernels from the distro.
David Lang

-

No it doesn't. Strange interpretations of peculiar US laws may be doing
Corporations practice "liability dumping" so that would be expected. They

want to dumb liability onto their suppliers, their customers and anyone

else they can find. Its the logical commercial practice faced by any

rational body evolving in the US marketplace.
But thats still their issue, no the community's issue. 
Alan

-