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
organizational pressure to use specific, pre-built kernels.
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
provided by their distro vendor.
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 had by doing something to the LSM
interface. Certainly a configuration option that statically inlines all
the hooks and points them at a compiled in module would yield some
performance gain, but I don't know how much. But that raises 2 questions:
1. Was *performance* really the reason this patch was proposed? Or
was it because James really did want the restrictive effect of
preventing people from choosing after-market modules and
dynamically unloading them if they want? I believe that James was
well-intentioned in trying to block these actions because he
believes them to be insecure, and he's right, they are insecure.
However, these actions are also very practically useful in many
circumstances. I disagree with the change because an individual
LSM can block both such actions if you wish, so imposing it on all
LSM modules is restricting choice unnecessarily.
2. Is the performance issue that this might address really big enough
to bother fixing at all? Maybe, but I don't know. Again, I'm
strictly opposed to the loss of flexibility until the performance
issue is documented, and then I would rather see it be a
configuration option you can choose to inline your module of
choice, rather than the default behavior.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Itanium. Vista. GPLv3. Complexity at work
-
