Advertisement
Front, Kernel, Security, Distributions, Development. See your byline here on LWN.net.
Weekly Edition
Return to the Kernel page
| |||||||||||||
|
| |||||||||||||
Some security hooks get the hook
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 removed.
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. (Log in to post comments)
Some security hooks get the hook Posted Oct 3, 2002 0:25 UTC (Thu) by gregkh (subscriber, #8) [Link] Heh, I wouldn't call myself the "LSM maintainer". There are a number of main LSM developers. I just have the "fun" task right now of funnelling the patches to Linus in bite-sized pieces.Also, the message here is a follow-up to the message linked to in this article, where I try to clear up my status about submitting hooks, yet again...
Some security hooks get the hook Posted Oct 3, 2002 17:37 UTC (Thu) by cpeterso (subscriber, #305) [Link] Why must every security module implement every security hook? This does not seem like a very forward-looking design. Why not have the LSM code implement the stubs itself? If a given security module does not implement some new hook, then LSM can use its safe stub that defaults to access-denied or something?
Some security hooks get the hook Posted Oct 3, 2002 18:52 UTC (Thu) by corbet (editor, #1) [Link] "Why must every security module implement every security hook?"My understanding from talking to the LSM folks is that they don't want new access control points to slip in without module authors being aware of them. Security-related programming requires a lot of attention to detail; the "you will implement every hook" rule is a way of forcing that attention, even when new details show up.
|
|
||||||||||||