On Tue, 2006-01-17 at 13:25 -0800, alan wrote: > Furthermore, it does a number of things differently than SELinux. It does > not just "duplicate a subset of SELinux functionality". It does not have > the problem of requiring a tagged filesystem like SELinux does. It allows > you to contain processes in a "chrootless chroot". It specifies what a > process can touch on the filesystem and how on a per application basis. Just to clarify (while trying to avoid a flamewar here about AppArmor vs. SELinux): Labeling the inodes with security information and then using that security information for the permission checks is a benefit of SELinux, not a drawback. It allows consistent protection of the files regardless of how they are referenced/named, and allows the real security characteristics of the file to be bound to the real object (the inode). It is consistent with the existing Linux discretionary access control mechanism which applies its checks based on the inode's mode, user, and group information. Pathnames are not a good basis for security checks, as a single file may be accessible under multiple distinct paths, each process can have its own distinct view of the namespace in Linux, renaming a file should not automatically change its protections, and the pathname doesn't tell us much about the security properties of the file at runtime. Also, SELinux can do what you describe (contain processes, control what processes can access what objects) and provides comprehensive controls over processes and objects. > I am not certain if the two can be merged or not. I have not tested the > latest kernel patches against an SELinux enabled kernel. I am planning on > doing it for my own use. The current Rawhide kernel is giving me fits > though. (The nvidia driver no longer builds.) They can't be merged easily (they both use the security fields and hooks provided by the LSM framework in the kernel), and it isn't clear what benefit would be obtained by merging them. -- Stephen Smalley National Security Agency
