On Wed, 2012-12-12 at 09:04 -0800, Casey Schaufler wrote: > On 12/12/2012 8:33 AM, Eric Paris wrote: > Yes, thank you. > > I'm headed in what I hope is a simpler direction. I have added > two files into securityfs: > > /sys/kernel/security/lsm - a comma separated list of LSMs > /sys/kernel/security/present - the presented LSM > > I have also added LSM identified files in /proc/.../attr: > > /proc/.../attr/current > /proc/.../attr/selinux.current > /proc/.../attr/apparmor.current > /proc/.../attr/keycreate > /proc/.../attr/selinux.keycreate > > SELinux applications and libraries can use simple logic to determine > what to do: > > if /sys/kernel/security/lsm does not contain "selinux" > Stop! No SELinux here! > if /sys/kernel/security/present does not contain "selinux" > Use selinux.current > else > Use current if you like. So if I use legacy tools for SELinux and Apparmor with a stacking kernel, they will both load policy and get things started. How would a legacy userspace know not to load it? But then they will both use /proc/self/attr/current even though only one of them owns it. So we get this half and half where one of them is enforcing a policy, but it can't actually really work... Maybe we just don't care. I'm ok with that answer. If you don't update userspace, don't build your kernel that way :) -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
