Smack For Linux Explained In Plain English

There has been plenty of activity in the Linux Security Module mailing list since Linus Torvalds posted in response to security programmers and researchers who don’t want Smack added to the 2.6.24 Linux kernel, because SELinux can do everything Smack can.

So what exactly is Smack? According to the website by the Smack author,

“The Simplified Mandatory Access Control Kernel (Smack) provides a complete Linux kernel based mechanism for protecting processes and data from inappropriate manipulation. Smack uses process, file, and network labels combined with an easy to understand and manipulate way to identify the kind of accesses that should be allowed.”

This is all fine and well , but begs the question, “Why is Smack so much better than the other offerings like SELinux or AppArmor?”

It combines the approach of both previously mentioned solutions by identifying a file by inode or by path. It primarily uses inodes, but then treats symbolic links as untrusted, resolving them to the path (and thus inode) when called.

AppArmor identifies files by the filename, while SELinux uses file number to determine what it should allow access to. This is GROSSLY simplified.

As far as Linus is concerned, Smack is better than the other options, because it emulates the functionality of SELinux, while maintaining a rather easy administration model. Easy administration means more people will use it. SELinux has been accused of being very difficult to understand and implement for any kind of complex installation.

Let’s do a simple comparison, this should speak for itself:

Smack Linux Source Code: 127549 characters.
SELinux FAQ HTML Source: 125701 characters.

If just the “Frequently Asked Questions” of SELinux is as large as the entire patch that contains Smack, which one do you think is easier to administer, almost by default?