Security

Dazuko and the LSM API

A recent commentary in The Inquirer led to quite a lively discussion in the LWN article that referred to it. The commentary itself was rather ill-considered, but it did raise some interesting questions about security modules, the kernel and the Linux Security Modules (LSM) API. Dazuko is one of a handful of security solutions that run on Linux, but are not maintained in the kernel tree and, in fact, have a relatively hostile attitude towards the suggested ways of moving their code into the tree.

Dazuko itself is a way for user-space applications to handle file access control; its main use seems to be malware checking at the file level, similar to the way that Windows anti-virus programs work. Some would argue that it is an unnecessary tool or that it is implemented poorly, but it does not seem like an unreasonable capability to add to Linux given that there appear to be users who want that functionality. This would seem to be exactly the kind of application that LSM was designed for, but the Dazuko developers have a different take.

Dazuko started out by using the LSM hooks to implement their application but claim they found LSM to be a moving target, changing the API between each kernel release. In addition, when other LSM using modules were loaded (most notably SELinux or AppArmor), as they are by default in various distributions, Dazuko no longer functioned correctly. This led the Dazuko developers in a direction that clearly will not fly with the kernel developers: system call hooking. This technique intercepts system calls (open, read, write, etc.) and runs Dazuko code before calling the actual kernel function.

This could be looked at as one of the common impedance mismatches between development groups and the kernel community; in this case it goes a bit deeper than that. Dazuko specifically mentions Rule Set Based Access Control (RSBAC) as a kernel security framework that it cleanly interfaces with. RSBAC is a set of kernel patches that implement a much more comprehensive set of hooks for access control than is provided by LSM. That project has a fairly lengthy justification for not using LSM and also points to another project, grsecurity with similar LSM issues.

There have been various discussions of removing LSM from the kernel along the way and the SELinux folks are strongly in favor of that. Up until this year's Kernel Summit (covered by LWN here), there was fairly widespread belief that it would happen. Few people, it seems, are particularly enamored with LSM. It was a compromise that was adopted when SELinux was being accepted into the kernel in order to allow other alternative security frameworks. For the most part, it has failed to do that; at least in the mainline kernel.

This situation would lead the hopeful to foresee a new API for the kernel that updates and enhances LSM so that more alternative frameworks could be incorporated into the kernel; unfortunately, there does not seem to be much movement in that direction. One impediment to that might be the perception that Linus and the kernel developers have rejected any security hooks that have a measurable performance impact. While it is perfectly understandable that punishing all kernel users for hooks that are only used by a small minority would be considered unacceptable, it does create a potentially insurmountable hurdle for those wishing for more intrusive hooks.

Dazuko has been working on a stackable filesystem that can provide the same kinds of services by mounting DazukoFS 'on top of' a regular kernel filesystem. This will allow Dazuko to work with approved kernel interfaces and leaves open the possibility that it could someday be moved into the kernel tree. Another alternative is to use the userspace filesystem (FUSE) interface to provide that functionality, though it is not clear that FUSE is able to solve the entire problem. For security frameworks that require more intrusive hooks, there is no real alternative to out-of-tree development. So RSBAC and grsecurity are likely to keep porting their patches to each new kernel as it is released. It seems unfortunate that these GPL-licensed alternative security mechanisms are unlikely to ever move into the kernel tree, but it appears they are caught between the proverbial rock and hard place.

Comments (4 posted)

asterisk: arbitrary code execution

Comments (none posted)

drupal: cross-site scripting, privilege escalation

Comments (none posted)

mod_tcl: format string vulnerability

Comments (none posted)

pike: SQL injection vulnerability

Comments (none posted)

qt: pixmap image handling vulnerability

Comments (none posted)