The future of the Linux Security Module API [LWN.net]

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 future.

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 security module.

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 distasteful.

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 published).
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.

(Log in to post comments)