LSM: loadable or static?

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.

Acomplaint 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:

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:

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.

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.

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.

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 :)

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 :) )

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

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

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?