Back in 2001, the very
first Linux kernel summit
included a discussion on security policies.
At that meeting, it was decided that there was no interest in patching in
the several competing implementations which were available at that time.
Instead, developers interested in security were asked to create a generic
interface which could be used by any security policy. The result was the
Linux Security Modules (LSM) API - a long list of hooks which can be used
to intercept almost any operation of interest within the kernel.
Last year, some developers were heard to mumble that perhaps LSM should be
removed from the kernel. Since LSM was merged, there has been only one
serious security mechanism using it to emerge: SELinux. Since there is
only one LSM user, and since SELinux can be thought of as a fairly generic
security framework in its own right, it is not clear that there is a need
for the LSM interface. The discussion died down last year, however, and
there has been little talk of yanking out LSM.
Until now. In response to a current discussion on LSM hooks, James Morris
has posted a patch adding LSM
to the "feature removal" schedule. The end of LSM is not a distant event
either: the proposed date is this coming June - the 2.6.18 kernel, in other
words. If this patch goes through, LSM will be gone in the very near
The early indications suggested that it could go through: several kernel
developers have argued in favor of the removal of LSM, while none
asked for it to be retained. The only disagreement - mild - was over the
removal date, with some arguing that 2.6.18 is too soon. Those in favor of
an early removal, however, claim that last year's discussion should count
as the usual one-year warning for this sort of change, and that there is no
need to wait any longer.
One might well wonder what the hurry is to remove this API from the
kernel. There is, in fact, more than just the "only one user" argument in
circulation. James's patch includes this text:
[LSM] also attracts a regular stream of misconceived and broken
security module submissions to mainline, such as BSD Security
Levels, and developers are seeing LSM as the answer to everything
rather than really thinking about what they need and how to
architect the code properly and generally.
So LSM becomes a general temptation to solve problems in the wrong way.
Beyond the security levels module (which, among other things, is seen as
having open vulnerabilities and no maintainer interest), the developers may
be thinking of past episodes like the debate over the realtime security
module or the Integrity
Measurement Architecture, neither of which is best implemented as a
The real issue, however, may be this one:
There is also a growing number of proprietary modules hooking into
LSM in unsafe ways, not necessarily even for security purposes. The
LSM interface semantics are too weak and such an API does not
belong in the mainline kernel.
The 2.6 kernel - intentionally - does not give loadable modules access to
the system call table. But the LSM interface is almost as good - it gives
a loadable module the opportunity to intercept almost any operation that
the kernel may attempt to perform. The LSM hooks are supposed to limit
themselves to internal record keeping and returning an allow/deny status to
the kernel - but there is no way to enforce that sort of restriction. The
GPL-only status of the LSM API does not help much either.
The people involved are wary of publicly pointing fingers at companies
suspected of misusing the LSM interface. One example which can be found,
however, is the kernel generalized event
management module which was posted to the kernel-mentors list last
year. When KGEM was loaded, it would shove aside any currently-loaded
security policy and install itself in its place. It would then feed
security-related events through to a (proprietary) user-space application,
which would make decisions aimed at protecting Linux users from the
pressing threat of virus attacks. There were a lot of issues over how this
module was implemented, but using LSM to override existing security
policies and provide hooks for proprietary code was considered especially
These reasons and strong developer pressure notwithstanding, it is not clear that
LSM will actually go away anytime soon. There is not yet a consensus that
SELinux should be seen as the One True Security Policy; many potential
users find its complexity hard to deal with and often simply turn it off.
The power of SELinux is unquestioned, but its usability is another story.
There are other users of the LSM API out there, they just have not been
submitted for inclusion into the mainline. These include:
- Novell's AppArmor, which is the security policy shipped with current
SUSE releases. AppArmor is free software, but has never been
submitted for review. The discussion of removing the LSM interface
appears to have lit a fire under some rear
ends at Novell, and
the first AppArmor submission is said to be imminent. (In fact, it
was posted just after this article was
Some of the
early discussion, however, suggests that AppArmor could have a hard
path into the mainline. In particular, its use of file pathnames as
the core of its security policy has been strongly questioned. In a
system capable of hard and soft links, multiple namespaces, shared
subtrees, and more, the meaning of any specific pathname is far from
clear. That is why SELinux uses extended attributes to apply
labels directly to files, rather than relying on their pathnames.
- The Linux Intrusion Detection
System (LIDS) is an LSM user. The LIDS developers have asked that
LSM not be removed, but have not made any statements regarding if and
when they might submit their module for merging.
- The Dazuko module is used by tools
like ClamAV. Dazuko seems somewhat like KGEM, in that it exports an
interface for user-space programs to make decisions. It is not clear
that such an interface can ever make it through the review process.
- Multiadm is a
module which allows privileges to be handed out to non-root users.
Given that security is something other than a completely solved problem, it
would be surprising if there were any single approach which was suitable
for all users. So something may well emerge and qualify as the second user
which keeps the LSM API in place.
Or, at least, which keeps some sort of API in place. If LSM stays around,
the kernel developers will probably make changes which make the API harder
to abuse. These might include finding ways to restrict what LSM hooks can
do and providing compile-time options to wire in a single security policy
at kernel build time. So, while there is a reasonable chance that future
kernels will include an LSM interface, it might be a rather different
interface than the one there today. Any security module developers who
want to have a say in how the interface evolves would be well advised to
join the discussion soon.
to post comments)