On Mon, 2005-10-17 at 17:02 -0400, James Morris wrote: > On Mon, 17 Oct 2005, David Safford wrote: > > > SLIM provides a simple integrity mandatory access control, similar > > to LOMAC, but using EVM information to aid decisions, and to ensure > > the integrity of guard processes. > > Can you explain why the Linux kernel needs SLIM when SELinux already > provides MAC and integrity control? > This is a fair question, and as Greg KH also pointed out, my posting should have explained more. While there is documentation in the referenced tar file, I should have explained more in the posting. First of all, I like selinux, and this is not an attempt to replace it. There are, however some interesting things that selinux does not currently do. It does not offer a LOMAC style policy, which seems (at least to me) much easier to understand, and less surprising to the user. It is easy to understand simple classes like SYSTEM, USER, and UNTRUSTED, and easy to understand that things like /bin, /usr/bin, /sbin, /usr/sbin, and /lib should be SYSTEM things which UNTRUSTED processes can read and execute, but not write. When I do a ps listing, I see the levels of all the processes at a glance, and this is easy to understand, even for a user. In addition, the ability to demote processes, rather than blocking them is very friendly for the user, even if they are trying to run a downloaded game. In addition, selinux does not have policies based at least in part on integrity of a file's data and metadata, and we wanted some MAC system to interact with EVM data and metadata authentication/access control. SLIM is an attempt to test these concepts in a stacked LSM environment. An interesting question is whether or not these ideas could also be implemented as modifications/policies in selinux. We did look at this, and thought it easier to test them separately first, and if they prove useful, then seeing if the selinux community would be interested in incorporating them (in a stacked framework, as we have other modules in work :-) dave
This archive was generated by hypermail 2.1.3 : Tue Oct 18 2005 - 13:13:37 PDT