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
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
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.
to post comments)