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
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).
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
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
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.
to post comments)