LSM: loadable or static?

By Jake Edge
October 24, 2007

The ever-contentious Linux Security Modules (LSM) API is being debated once again on linux-kernel, not its removal, which Linus Torvalds came down firmly against, but whether it should allow security modules to be loaded dynamically. As part of 2.6.24, Torvalds merged a patch to convert LSM into a static interface, but has indicated a willingness to revert it. The key sticking point is whether there are real security modules that require the ability to be runtime-loaded.

A complaint by Thomas Fricaccia about the change caused Torvalds to put out a call for folks using module loading with their LSM code. The patch could be reverted if there are "real-world" uses for that ability. Torvalds again questions the sanity of security developers, but is clearly looking for someone to step up:

I'd like to note that I asked people who were actually affected, and had examples of their real-world use to step forward and explain their use, and that I explicitly mentioned that this is something we can easily re-visit.

Jan Engelhardt responded with information about his MultiAdmin module, which allows multiple root users on a system, each with their own UID. This allows separate tracking of file ownership, resource usage and the like for each administrator. MultiAdmin also allows for the creation of sub-administrators who can perform some root activities for processes and files owned by a subset of users. The use case he cites is for professors being allowed to administer their students' accounts without getting full root privileges.

James Morris, who proposed the static LSM change, responded that MultiAdmin seemed to qualify as a real-world use under Torvalds's criteria. Though it is not clear that MultiAdmin requires a loadable interface, it does use it. The venerable root_plug security module – which only allows root processes to start if a particular USB device is plugged in – also implements loading and unloading. In both cases, configuration could be done via sysfs parameters with an enable flag to turn them on or off.

To some extent, for the examples offered so far, loading is a convenience for administrators, but the major users for unloading are developers. Crispin Cowan sums it up:

Why would you want to dynamically unload a module: because it is convenient for debugging. Ok, so it is unsafe, and sometimes wedges your kernel, which sometimes forces you to reboot. With this patch in place, it forces you to *always* reboot when you want to try a hack to the module.

Other justifications for leaving the LSM loadable interface in the kernel have been less compelling. It is hard to imagine that the US Sarbanes-Oxley regulation would allow loading security modules into a running kernel, but not allow the kernel to be rebuilt as Fricaccia suggested. Inserting proprietary security modules that are provided from the vendor in a binary-only form seems foolhardy – this kind of potential abuse is the kind of hole Morris's patch was meant to close – but could be seen as a reason to allow LSM loading.

A compromise may have been found in a patch posted by Arjan van de Ven, which converts LSM to be either static or loadable depending on a compile-time kernel option. A consensus seems to be building that this is a reasonable approach, allowing distributions and users to decide for themselves whether they will allow security modules to be loaded. As of this writing, Torvalds has not weighed back in with a decision and the newly released 2.6.24-rc1 kernel has the static patch.

Dynamic loading of security modules is a potential source of problems – what better place for a rootkit to hide? – but there are valid reasons that someone might want to use it. Linux strives to be open to many uses, including some that the kernel hackers might find distasteful; dynamic security modules would seem to be one of those uses.

Index entries for this article
Kernel	Security/Security modules
Security	Linux Security Modules (LSM)

LSM: loadable or static?

Posted Oct 25, 2007 9:09 UTC (Thu) by jcm (subscriber, #18262) [Link] (1 responses)

Personally, I think it's absolutely essential to be able to build a kernel with dynamic LSM.
Whether we like it or not, people do want to add in runtime loadable security modules for
things like virus scanners, and until upstream offers these folks a viable alternative to
LSM...well, they'll use it.

Jon.

LSM: loadable or static?

Posted Jan 25, 2008 14:14 UTC (Fri) by Dwokfur (guest, #50126) [Link]

So do I.
One example is: dazuko for on-access virus scanning.
http://lwn.net/Articles/206075/

If Linux wants to care about security, he should move on and incorporate PaX, Grsecurity or
RSBAC.

Using Grsec you can load whatever modules you want at start time, and keep the system in that
states blocking further module changes. This is a better working approach, which takes care
more than just the LSM subsystem.

Regards,
Dw.

LSM: loadable or static?

Posted Oct 25, 2007 12:52 UTC (Thu) by nix (subscriber, #2304) [Link]

A stylistic note: the use of last-names-only sounds really *strange* in this context, probably
because everybody actually doing development uses first names wherever practically possible :)

LSM: loadable or static?

Posted Oct 25, 2007 13:03 UTC (Thu) by nix (subscriber, #2304) [Link]

A rootkit can trivially hide wherever it likes if module loading is enabled: rootkits don't
respect the exportedness of symbols.

(Most common rootkits can inject themselves by banging directly on /dev/mem. It will be good
to finally eliminate the ability to write to that device... come on pci-rework, we want X to
not depend on /dev/mem anymore :) )

LSM: loadable or static?

Posted Oct 25, 2007 14:24 UTC (Thu) by walters (subscriber, #7396) [Link] (2 responses)

Wouldn't virtualization (something lightweight like lguest) work well for security system
developers?

LSM: loadable or static?

Posted Oct 25, 2007 15:30 UTC (Thu) by jengelh (guest, #33263) [Link]

Details about how I have to imagine that? (Perhaps post to LKML, too.)

LSM: loadable or static?

Posted Oct 25, 2007 22:37 UTC (Thu) by jamesm (guest, #2273) [Link]

That has already been suggested at least twice. It takes about the same amount of time to boot a kernel under lguest as it does to load a module. You can script it, as lguest output can be redirected, and don't corrupt the system when your code has a bug. It would be great if people actually followed the discussion.

Interesting question.

Posted Feb 1, 2008 17:52 UTC (Fri) by jd (guest, #26381) [Link]

Loadable security modules are a potential problem, because there's a time prior to them being loaded when the system is potentially insecure. Well, maybe. That would seem to depend on the default access rights. It would seem perfectly possible for certain components to have automatic denial of access unless specifically permitted (a generalization of the ideas in mandatory access controls). In which case, loadable security modules would be less of a security hole.

The only context I can think of is where you have specific needs (such as maintenance of embedded systems) that need special rights but are so infrequent that having the code for those rights permanently present is inefficient use of memory and CPU cycles. This only matters, though, when one or both of these are so heavily constrained that even the tiny difference made by an LSM module would have a significant operational impact.

The question then becomes one of whether the mainstream kernel should actively support such special cases. Are they common enough to be mainlined, or rarities that shouldn't be actively prohibited by kernel design but only really supported by an external patch?