OLS: Smack for embedded devices

The Simplified Mandatory Access Control Kernel (Smack) is a Linux access control mechanism akin to SELinux. As its name would imply, it is a much less complex scheme that requires far fewer resources than SELinux, which may make it more palatable to developers of embedded systems. Smack developer Casey Schaufler gave a talk at the recent Ottawa Linux Symposium (OLS) outlining how it could be used for embedded devices.

Smack has the distinction of being the second user of the Linux Security Module (LSM) kernel interface to be merged into the mainline. This finally put to rest the idea that the LSM might some day be removed from the kernel, requiring all security solutions to be implemented in terms of SELinux. But Smack comes at Mandatory Access Control (MAC)—which is at the heart of both SELinux and Smack—from a different perspective. Schaufler believes that MAC rules should be explicitly specified rather than implicit in a set of policies a la SELinux.

In order to get everyone up to speed, Schaufler gave an overview of MAC and Smack. The main thing to remember about MAC is that it is not user controlled. The system makes all decisions about access and the attributes of files that govern access. The standard UNIX model, by way of comparison, is a Discretionary Access Control (DAC) system, where users can change the security attributes of objects under their control.

Smack relies on labels for subjects, which are active entities, and objects which are passive. An access is then an operation that is performed by a subject, generally a task/process, on an object, which is typically a file. In order to determine whether the access succeeds or fails, Smack compares the subject and object labels, if they match access is granted, if they do not match, the explicit access rules are consulted. If one matches the attempted access, it is granted, otherwise it is denied.

There are three system labels defined, along with access rules governing their behavior, but all other rules must be explicitly added by the administrator. Labels are simply strings up to 23 characters long. Rules then specify a subject label, an object label, and a desired access (read, write, execute, append). After mounting a smackfs filesystem at /smack, rules can be written to /smack/load, which stores them in the kernel for immediate use.

It is important to note that objects inherit the label of the subject that creates them. That means that the label on an executable is only relevant to determine whether the subject process is allowed to execute it. The process that gets created has the label of the subject that executed it, not the label associated with the executable file. The same goes for processes that create files, those files get the label of the process. This is very different from the SELinux label inheritance rules.

There is more to it, of course, but not a lot more, which is what makes it attractive to some. Interested readers are directed to our article, Schaufler's OLS paper [PDF], or the Smack home page for more detailed looks at Smack.

Schaufler outlined specific reasons that a simplified system, like Smack, would be attractive in the embedded world. Many embedded devices are single-purpose and geared towards one user. Because cost is often a major factor, the device only needs to implement the exact set of functions that it is meant to provide. As Schaufler puts it: "feature completeness is uninteresting".

Cost often plays a role in the amount of system resources provided, particularly RAM and flash, as well. A solution that uses less memory fits well with the embedded mindset. There have been some efforts to pare down SELinux and its enormous policy file for the embedded world (including a paper at OLS [PDF], and a presentation at the Embedded Linux Conference that we covered briefly), but it is still rather large. It is also a great deal more complex than Smack, which was a major thrust of Schaufler's presentation.

One problematic area for putting SELinux on embedded devices is that most flash filesystems do not have support for extended attributes (xattrs). Both Smack and SELinux use xattrs to store labels for files, but Smack can provide a default label for an entire filesystem to avoid requiring xattr support. Also, system files automatically default to the "_" (called floor) label so, in many cases, labels on individual files may not be required.

In his talk, Schaufler gave several examples of specific sets of applications and how they could be easily cordoned off from each other while still working together. The model he used was of a mobile phone with multiple applications. The phone's system data would have the default floor label which means they can be read—but not written—by a process with any label.

One of Schaufler's examples was of two different applications that each retrieved content from the network to display to a user. Each retrieved headlines from different services, one from CNN, the other from ESPN. At times the content might overlap, in which case the phone vendor wanted each to be able to read the other's data, potentially displaying a sports story as part of the regular news or vice versa. This is easily handled by two Smack rules:

    ESPN CNN r
    CNN ESPN r

Assuming that the CNN application runs with the CNN label, and the ESPN process with ESPN, they can each read and write their own private data (because the labels match). Because of the two rules above, they can also read each other's private data. If at some point, the phone provider decided those two applications should not be able to share data, those rules simply need to be removed, no filesystem relabeling or anything else is required.

Another example that Schaufler gave was of a video process and an audio process that cooperated in sharing system resources by sending messages to each other. They had no need to share data, just to send UDP messages. In Smack, a process can send a UDP packet if it has write access to the label of the other process. So the following Smack rules could be used:

    Video Audio w
    Audio Video w

One might expect that giving write permission would allow Video, for example, to write to data with the Audio label. This is not the case because UNIX file semantics require read access in order to write file data (because the inode of the file must be read). So under this set of rules, each can send (and receive) UDP packets from the other process, but cannot access any of the data labeled for the other process.

Schaufler had some other examples in his presentation (slides [PDF]), that were geared more towards exploring Smack capabilities than specifically at embedded applications. He concluded by directly comparing Smack and SELinux in terms of complexity. Clearly Smack is vastly simpler; whether it has enough capabilities to provide the protection that embedded developers require remains to be seen. On the other hand, whether SELinux can be made to work reasonably in embedded environments is also an outstanding question. It will be interesting to watch.