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
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.
to post comments)