Go to:

IT Jobs

Long-time LWN readers will know that the Linux security module (LSM) API is controversial at best.

To many, it has failed in its purpose, which is enabling the development of competing approaches to hardened Linux system; the only significant in-tree security module remains SELinux.

Meanwhile, the LSM interface is easily abused; since it allows the insertion of hooks into almost any system operation of interest, it can be used by other modules to provide non-security functionality. The LSM symbols are mostly exported GPL-only, but it is still possible for binary-only modules to abuse the LSM operations - and, apparently, some have done so.

SELinux hacker James Morris has been pondering this issue recently; he has also noticed that the in-tree security modules (SELinux and the small module implementing capabilities) cannot be unloaded. So, he asked, why implement a modular interface at all? He has posted a patch which turns LSM into a static API with no exported symbols. With this patch applied, any needed security "modules" must be built into the kernel; there is no longer any way to add them at run-time.

There have been a few complaints but, from the author's point of view, it does not seem like anybody has come up with a compelling reason why it must be possible to unload security modules. Instead, it has been pointed out that maintaining a coherent security state in the presence of unloadable modules is nearly impossible. So this patch would appear to have reasonably good chances of being applied. The only question, perhaps, is whether the developers feel the need to provide an extended warning period for developers and users of out-of-tree security modules.

One such module is AppArmor - the GPL-licensed security mechanism distributed by Novell.

AppArmor has remained out of the tree for a long time while its developers have tried to address the various comments which have been posted over the years. A new AppArmor patch has been posted; many things have been fixed, but one of the core points remains: AppArmor still uses a pathname-based mechanism for its policy enforcement. This approach sits poorly with developers - especially those in the SELinux camp - who think that pathnames are an inherently insecure method. In their view, the only truly secure way to control access to objects is to put labels on the objects themselves.

It seemed that this dispute had been resolved at the 2006 kernel summit, where it was determined that the use of pathnames was not enough to keep AppArmor out of the kernel. That has not stopped people from complaining though, and those complaints redoubled when another pathname-based approach (TOMOYO Linux) was posted recently. If AppArmor does get into the mainline, it will have to be over the objections of developers who feel that is providing false security to its users.

Andrew Morton appears to want to resolve this issue and get it off the mailing lists; he sees two alternatives:

a) set aside the technical issues and grudgingly merge this stuff as a service to SuSE and to their users (both of which entities are very important to us) and leave it all as an object lesson in how-not-to-develop-kernel-features.

b) leave it out and require that SuSe wear the permanent cost and quality impact of maintaining it out-of-tree. It will still be an object lesson in how-not-to-develop-kernel-features.

It seems that Andrew would rather not be in the position of delivering object lessons on how not to develop kernel code by whatever means; he concludes with this request: "Sigh. Please don't put us in this position again. Get stuff upstream before shipping it to customers, OK? It ain't rocket science."

At the 2006 summit, Linus took a clear position that the use of pathnames for security policies seemed reasonable to him. Given that, along with the fact that AppArmor is being widely distributed, and it seems that, sooner or later, this module should find a home in the mainline - even if it is no longer in modular form.

Latest White Papers

10 key actions to reduce IT infrastructure and operations cost structure
>> Download whitepaper

Using managed services to reduce costs and sustain growth in mid-sized organisations
>> Download whitepaper

Unleashing the power of iLO, IPMI and other service processors
>> Download whitepaper