Red Hat Bugzilla – Bug 156599
Default Linux Capabilities should be compiled as a module
Last modified: 2012-06-20 11:59:52 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3 Description of problem: The Default Linux Capabilities LSM module does not support stacking and if other LSM modules need to be loaded, they have to be loaded before Capabilities. If Capabilities is built into the kernel, it is not possible to load any other LSM modules before it. A sample kernel module which suffers from this condition is Dazuko (http://www.dazuko.org). Especially see http://www.dazuko.org/tgen.shtml#FEDORA In the future kernels, please ship Capabilities compiled as module, thank you. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Download Dazuko from http://www.dazuko.org 2. Try to install it. 3. modprobe or insmod of the dazuko kernel module fails. Actual Results: Actually, new dazuko releases detect the fact that capabilities are builtin and do not even bother to compile. Expected Results: Dazuko configure should complete successfully and running 'make' should produce a module that can be loaded, if loaded before capabilities. Additional info:
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.