LWN.net Logo

Smack for simplified access control

By Jake Edge
August 8, 2007

SELinux provides a comprehensive security solution for Linux, but it is large and complex. A much simpler approach is taken by the Simplified Mandatory Access Control Kernel (Smack), a patch posted to linux-kernel by Casey Schaufler. Like SELinux, Smack implements Mandatory Access Control (MAC), but it purposely leaves out the role based access control and type enforcement that are major parts of SELinux. Smack is geared towards solving smaller security problems than SELinux, requiring much less configuration and very little application support.

Smack allows an administrator to define labels, 1-7 characters in length, for kernel objects. Labels on objects are compared with the labels of a task that tries to access them. By default, access is only allowed if the labels match. There are a set of Smack-reserved labels that follow a different set of rules, which allows most system objects and processes to be unaffected by Smack restrictions. By default, Smack does not get in the way of the OS, allowing the administrator to concentrate on just the users and processes they want to secure.

Smack uses filesystem extended attributes to store labels on files; administrators set the labels using the attr command. The security.SMACK64 attribute is used to store the Smack label on each file, so setting /dev/null to have the Smack-reserved "star" label would look like:

    attr -S -s SMACK64 -V '*' /dev/null
For networks, NetLabel is used to set CIPSO labels and domains of interpretation for sockets, allowing Smack systems to interoperate in those strictly controlled networking environments.

An administrator can add rules, but there is no support for wildcards or regular expressions; each rule must specify a subject label, object label and the access allowed explicitly. The access types are much like the traditional UNIX rwx bits, with the addition of an a bit for append. For configuration, Smack uses the SELinux technique of defining a filesystem that can be mounted, smackfs. Typically, it will be mounted as /smack, providing various files that can be read or written, to govern Smack operation. For example, Smack access rules are written to /smack/load; to change rules, one just writes a new set of access permissions for the subject-object pair.

An example, one of several provided in the patch announcement, uses the standard security levels for government documents. Smack labels are defined for each level: Unclass for unclassified, C for classified, S for secret, and TS for top secret. Then, with a handful of rules:

        C        Unclass       rx
        S        C             rx
        S        Unclass       rx
        TS       S             rx
        TS       C             rx
        TS       Unclass       rx
the traditional hierarchy of access is defined. Because of the Smack defaults, Unclass will only be able to access data with that same label, whereas because of the rules above, TS can access S, C and Unclass data.

Note that there is no transitivity in Smack rules, just because S can access C and TS can access S, that does not mean that TS can access C. That rule must be explicitly given. Also, because no write permissions have been given, tasks at each level can only write data with their own label. So secret tasks write secret data and so on. Files will inherit the label of the task that creates them, with Smack ensuring that the filesystem attribute is set. They will retain that label unless it is explicitly reset by an administrator using the attr command.

A patched version of sshd is available from Schaufler's homepage which allows an administrator to assign labels to users. Those labels get set on the user's shell and terminal device as they log into the system, forcing the user to follow the rules established for their label. A patched version of ls is also available so that it can display the labels associated with files.

Smack is useful for limiting user and specific process access to various resources, it is not meant to be as general purpose as SELinux. Constructing a set of Smack labels and rules governing system processes, network services and the like, to restrict their access as SELinux does, would be impossible. For administrators needing to secure those services, SELinux is probably a better tool, but for simple compartmentalization, Smack may well suffice.


(Log in to post comments)

Smack for simplified access control

Posted Aug 10, 2007 22:05 UTC (Fri) by bronson (subscriber, #4806) [Link]

I love the idea of simple but I wish Smack could have been more SELinuxish... I would be very happy to adopt it now if I could easily move my profiles to SELinux when I need more capability. Slippery slopes are great for attracting a captive audience!

As it is, if I learn Smack now and it turns out it doesn't do everything that I need, I'd then need to re-do everything from scratch in SELinux. Therefore, I'm inclined to just start in SELinux, especially because it's got a fair amount of momentum behind it.

Is this a fair assesment? Or are Smack and SELinux more similar than I thought?

Copyright © 2007, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds