Security: Objects vs. Names

Emily writes about the annual kerfluffle known as LSM vs. SELinux and I've been reading the coverage on slashdot and kerneltrap with some amusement lately. Last year this was again coming to a head around the time of the Linux Kernel Summit and one of the topics was to have the AppArmour/LSM folks and the SELinux folks get together to talk about how to resolve their differences. And, in the end, they were unable to resolve them, although the reason is that LSM and SELinux take two different approaches to security - both valid, but roughly incompatible.

SELinux was started by the NSA and provides an appropriate level of security for people that are really paranoid about the security of specific "objects" - files, directories, pipes, shared memory, etc. The SELinux people strongly believe that the goal is to protect an object by all means necessary, and all permissions are ultimately associated with that object. This allows for both Discretionary Access Controls (where I can give you access to my directory or file with chmod(1) or some form of Access Control List (ACL), and for Mandatory Access Controls (someone gave me a file which requires certain permissions, and I can not open that file up to someone who does not have those permissions - think of it more like Classified documents). With SELinux, all objects have their own security traits and they are completely unrelated to the name or location of that file.

This obviously sounds like good stuff for security; however, the downside is that the implementation of object based security has been a bit more invasive on the kernel side, very difficult to use and configure from the system administrator side, and started life in early deployments as the feature that was always shut off to get it out of the way. In other words, it often crossed the line between usefulness and security. This is where that age old comment that the only secure system is the one that is unplugged in a locked room buried under ten feet of concrete" comes in. Usability typically drops as security goes up.

LSM provides another mechanism related implementing security. It starts with the premise that every object has a name. That seems simple enough, right? In fact, most of us don't talk about the file that holds all of the kernel messages, but instead we refer to /var/log/messages (or your system's equivalent) as the place where logs are stored. In fact, pretty much every interesting object has to have a name - and probably a name in the filesystem (there are some exceptions to this but that isn't really important here). And, LSM works from the premise that systems administrators know the names of the files that they want to protect or manage. Therefore, why not provide a security mechanism which takes as its primary "handle" for accessing an object a filesystem path name? And, from that small shift in fundamental focus, SELinux and LSM tend to diverge while both providing very strong, or sufficiently strong system security mechanism.

A more interesting difference between the two shows up when one wants to audit all actions on a file. Let's say I'm monitoring /var/log/auth.log watching to see who becomes root on my system. In SELinux, I might monitor all reads and writes to /var/log/auth.log. But what if someone moved /var/log/auth.log to /var/log/auth.hide? SELinux would continue to monitor my moved object for changes, even though it isn't the place where the current notification of reads and writes was happening. And, just supposed that some black hat at the end removed the new /var/log/auth.log and put back the /var/log/auth.hide as the new log? It might appear as though the entries of the black hat hacker just disappeared! Of course, we've monitored all reads/writes to /var/log/auth.log and the audit logs may not show the problem. This is a case where LSM track actions on the path /var/log/auth.log no matter what object it pointed to. Of course, this case is a bit contrived, but shows the point. In reality, we'd probably monitor all reads, writes, moves, truncates, creates, etc. of the object in question and in both SELinux and while using LSM we'd be able to track the black hat.

One final point regarding the pluggable debate - SELinux allows a single, fixed mechanism with some policy extensions. If it doesn't have the right capabilities or permission controls, well, you just can't monitor something. LSM provides a pluggable/semi-stackable (I'll stay out of the politics of this one at the moment) interface, which means that you can create more complex rules for denying access to files. One part of the debate is whether or not LSM should have that flexibility - what if you stack a function which doesn't just permit or deny access, but instead adds extra functionality? Who monitors that functionality to ensure that it does not in some way corrupt the kernel or make some locking layering violation, or simply changes some existing priority scheme by allowing access to a file inappropriately? The problem with flexibility is that it is like the rope you can use to hang yourself or the rope to build a more comfortable hammock. There is more concern about people using hooks to do the former (like in Spiderman - "with great power comes great responsibility").

But yet again (and probably indefinitely) *both* security policies are in to stay, while people play with both until some new mechanism emerges that is better than either.