The Linux Security Module code works by allowing security-related code to
hook into almost every access decision the kernel makes. Security modules
can only tighten restrictions by vetoing access that would have otherwise
been around. A number of security regimes - most notably the NSA's SELinux
- have been built on the LSM structure. The LSM patch has been partially
merged into the kernel; many of the LSM hooks are not yet there, however.
Recently some developers have been questioning some of the specific hooks.
In response, LSM maintainer Greg Kroah-Hartman has posted a patch removing a few LSM hooks: those for
creating, initializing, and deleting modules. Nobody seems to have an
issue with the ability to control those operations - it's just that no code
is currently using those hooks.
That is, in fact, Greg's stated policy with
LSM: any hooks that are not
actually being used by an available, open source security module will be
I am not happy with the idea that there would be hooks in the
kernel that are not being used. That's not the Linux way. If the
code isn't being used, it's removed.
The idea, of course, is that there is no point in trying to maintain code
that is not in use. By the time somebody actually tries to make use of it,
chances are it will be broken anyway. And, it is said, it is easy to
reintroduce a hook should the need develop.
Of course, given the LSM design, it's not that easy to put in a new
hook. LSM requires security modules to provide an explicit implementation
for every available hook, with the result that security modules accumulate
a lot of stub "no-op" hooks. Adding a hook will break every security
module out there until they implement a stub for that hook. Given that,
security module authors who see a use for some of the more obscure hooks
might want to document that use before too long.
to post comments)