SMACK meets the One True Security Module

This article brought to you by LWN subscribers Subscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible.

The Simplified Mandatory Access Control Kernel is a security module designed to harden Linux systems through the addition of mandatory access control policies; it was covered here last August. Like SELinux, SMACK works by attaching labels to processes, files, and other system objects and implementing rules describing what kinds of access are allowed by specific combinations of labels. Unlike SELinux, though, SMACK was designed specifically for simplicity of administration.

The posting of version 3 of the SMACK patch inspired a certain amount of discussion. Andrew Morton's take led things off:

Andrew concluded by suggesting that the SMACK patch should be merged for 2.6.24. There was some discussion about specific pieces of the patch (some developers are more impressed by CIPSO network labels than others), but there does not seem to be a whole lot of opposition to merging the SMACK security module. It is generally seen as being well-written code which makes sense from a security point of view.

There was one predictable exception, though: whenever a new security module is considered for merging the SELinux developers tend to oppose it. This time, James Morris voiced a more general complaint: SMACK would become the second in-kernel user of the Linux security module (LSM) framework. That, in turn, would make it almost impossible to remove LSM from the kernel. James claims:

The SELinux programmers, it seems, would rather that SELinux became the one security framework supported by Linux, with all development effort going into making SELinux better.

The problem, of course, is that, even after a few years with only SELinux in the kernel, there has not been a glut of application developers working to support it. The vision of each application shipping with an SELinux policy file has not come to be. Some progress has been made in the creation of higher-level tools for the management of SELinux policies, and the Fedora and Red Hat developers have come a long way toward making a general-purpose distribution work with a limited set of SELinux policies, but SELinux simply remains too complex for most people to deal with. SELinux may work out of the box on an RHEL system, but as soon as the system administrator runs into something which breaks, chances are that SELinux will be turned off.

The SELinux developers would presumably argue that the way to address these problems is to focus on a single security framework within the kernel. Rather than create competing, simplified frameworks, it would be better to implement approaches like AppArmor or SMACK within SELinux and, in the process, make SELinux better. Those developers argue that pluggable security modules, like pluggable schedulers, succeed only in splitting development effort and preventing the creation of a truly general solution:

The answering argument is that there are many security environments and differing sets of user needs; there is no sign that a single security approach can ever work in all situations. And, even if such a unified approach were possible, getting security developers to agree on it would still be a major challenge. Ted Ts'o writes:

The LSM architecture was a result of the very first kernel summit, where Linus stated that he had no wish to choose between the various security ideas in circulation and, instead, wanted the kernel to be able to support all of them. He has not changed his mind since; he still doesn't see any imminent consensus on security approaches, and still wants Linux to be flexible in this regard. So his pronouncement was:

So it looks like the way is clear for a merger of SMACK in 2.6.24. Once that happens, it would not be surprising to see another push made by the developers of security modules like AppArmor and TOMOYO Linux; in fact, the TOMOYO Linux patches have just been reposted. In the end, SELinux will, despite the apparent wishes of its developers, have to compete with other security approaches for attention from developers, distributors, and users. There will be no One True Security Module for Linux in the foreseeable future.

Index entries for this article
Kernel	Security/Security modules
Security	Linux Security Modules (LSM)

---

(Log in to post comments)