Impossible to fix for RHEL4 due to KABI breakage.
This was a design decision made during RHEL4 development.

Dazuko looks like a nice project to me.

Sami, do you know if f-secure has any plans to make LSM stackable and get dakuzo
into the upstream kernel?

LSM is already stackable, but only if the LSM modules participate. The
capability module does *not* participate, which breaks stacking. Fortunately
dazuko does support stacking, so if dazuko is loaded before capability, there
are no problems.

However, since capability is being compiled in the kernel, stacking is broken
"out of the box". By compiling capability as a module, users would have the
ability to load "stacking-friendly" LSM modules before loading capability.

I do not understand how compiling capability as a module rather than built-in
would cause KABI breakage. Could someone post more detailed information about this?

I think we need to reset this discussion to
a) focus on the problem we are trying to solve instead of a specific solution,
b) make sure we are in sync with the upstream kernel development, and
c) work out a solution for future releases and then see how to translate that
for existing ones.

The problem, if I understand right is online-virus-scanning. What else?

This makes the first question regarding the upstream direction: is LSM the right
hook for that? Or are there better alternatives? E.g. would a overlay filesysem
be better? If LSM is right, I think the proposed LSM needs to be submitted into
the upstream kernel before we can consider enabling it.

I answer to comment 8: For RHEL we guarantee stability of the exported kernel
runtime environemnt for the whole lifecycle of the release. Changing to modular
LSM (regardless of any other arguments for or against it) is considered to break
that guarantee. So that message translates into: even if we wanted to switch, we
could not.

The problem in general is the capability system which is unable to accommodate
other LSM modules. Specifically the application I am interested in is real-time
virus scanning (or on-access virus scanning).

Currently LSM has been problematic for this use:

a) Customers running Red Hat need to compile their own kernel with capability as
a module.

b) LSM kernel API has changed in almost every kernel release. (Which, I
understand, is not a problem if the customer runs a RHEL kernel, because you
guarantee binary compatibility between kernel versions.)

c) The LSM hook normally used has been the inode_permission call. This is called
when files are opened or executed, but there is no call for file close. Scanning
files on close is important for viruses to be found immediately after they are
written onto disk. Otherwise a virus would lie on the disk dormant until the
file was opened. Possibly the disk could be a removable disk and the file can be
opened in a system that has no real-time virus scanner.

The dazuko driver has successfully used syscall hooking for a while now.
However, it has some problems too: Implementing the hooking is difficult, it
cannot trap file access of kernel processes like NFS server and it is vulnerable
to some attacks.

The dazuko maintainer, John Ogness, has been looking into overlay file systems.
There the problem is that the overlay file system needs to be mounted somewhere.
 The underlying file system may still be visible to users from its original
mount point. It is also unclear if it is possible to overlay the root file
system. This may not be a problem if only users' home directories are to be
scanned. However, there are some software, e.g. the F-Secure Linux Client/Server
Security that have additional system integrity checking features, which need to
control access to /, /bin, /usr and /lib in order to do real-time system
integrity checking.

This bug report was opened more than 2 years ago. Obviously we were not
expecting Red Hat to fix it anymore. We have moved to use syscall hooking while
investigating other possibilities. As far as I am concerned, this bug can be closed.

However, it would be nice if you could consider compiling capability as a module
next time you are breaking binary compatibility in your RHEL kernels. Just in
case we or others have some other need for LSM...

Well, the general problem here is, that this issue has to be resolved in the
upstream kernel. Instead of hacking into other interfaces that were designed for
other purposes, someone needs to design a clean interface for
online-virus-scanning, post that patch to lkml and get it accepted into Linus'
kernel. That is the ONLY way to solve this issue. 

We are happy to participate in this.

Other solutions simply don't work long-term. We have good reasons why we compile
LSM statically and we never supported it as an interface for 3rd party
applications (and I am being told that it is going away upstream aswell). Now
while in Linux you legally and technically can use unsupported interfaces, it
still is a VERY bad idea... And even if we wanted to enable modular LSM, we
could not do that in an already released product. That is considered to be
breaking our kernel ABI and that is not an option. The syscall-table-hacking on
the other hand is considered a root-kit technique that AFAIK is going to be
disabled upstream as well (if it is not already). So these approaches are not
going anywhere.

So we really have to get serious, define requirements for a generic interface,
get this accepted upstream and then back-port it. This is how Linux-kernel
development works.

It seems that Dazuko has no way to intercept writes, so a file could be infected
undetected simply by keeping it open and infection can be spread to other
programs that already have the file open.

/* event types */
#define DAZUKO_ON_OPEN                  1
#define DAZUKO_ON_CLOSE                 2
#define DAZUKO_ON_EXEC                  4
#define DAZUKO_ON_CLOSE_MODIFIED        8
#define DAZUKO_ON_UNLINK                16
#define DAZUKO_ON_RMDIR                 32
#define DAZUKO_TRUST_REQUEST            64

This looks like false security to me.  We will have to come up with something
better than Dazuko to have a snowball's chance in hell of getting merged into
the upstream kernel...

I wonder what threat models the anti-virus programs do and do not protect
against?  Maybe users simply don't care about a few security holes in their
anti-virus software, as long as the virus is detected eventually?

Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.