Wednesday, October 03, 2007

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.

Labels:

2 Comments:

At 2:35 PM, Blogger Emily said...

Again that word kerfuffle - I love it!

One thing to keep in mind is that the SELinux folks were key developers were LSM. LSM is the framework of hooks - in and of itself it has no security attributes. The only apparent criticism of LSM is that it is unnecessary (everything can be done as a SELinux policy) and that it allows people to choose things that they shouldn't want.

The premise that every interesting object has a name is an attribute of AppArmor; LSM deals with kernel objects rather than names. Maybe I'm misunderstanding your point, but I think you just typoed/brainoed LSM for AppArmor.

>SELinux allows a single, fixed mechanism with some policy extensions
Again, to be fair to SELinux, their design which separates policy from enforcement does give them a high degree of flexibility and many if not most security modules can be emulated by writing the correct policy. The only trouble is that there are maybe 3 people in the world qualified to do this, and they are all busy.

 
At 5:38 PM, Blogger Gerrit said...

Emily - yep, you are right. I distilled down the kernel argument which centered really around LSM as a way to provide an access to each object by its name. AppArmor provides a policy and mechansism using LSM which focused on the name of hte object. If I remember correctly, LSM does a name lookup for each traversal of the LSM hook(s). SELinux provides more of a lifetime approach for access to the object - the object is always validated by its inode/permanent attributes for that object, as opposed to accessing it via the objects name, which may be changed. Now, that is a pretty fine hair to split, and that is why Linus finds the security folks a little crazy. After all, every inode can only be found originally by its name, and also must have a name if it is to be accessed or protected.

But nonetheless, your point is valid that LSM is only the building block, the hooks upon which a larger policy can be built. A larger policy which some have argued could be *too* flexible thus potentially compromising the systems security. SELinux embodies that policy and policy engine in a way which does not allow a typical user or user level environment to compromise that security, at least in principle. LSM allows flexibility and pushes more policy to user level, which scares the folks that like to have tighter controls.

 

Post a Comment

Links to this post:

Create a Link

<< Home