/proc/filesystems to look for selinuxfs then /proc/mounts to find selinuxfs assuming it isn't at /sys/fs/selinux or /selinux I'd guess it is ssh failing closed, not the library, but in either case, it's the right thing to do in enforcing and could probably be considered a bug in permissive... On Wed, Dec 12, 2012 at 12:16 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: > On Wed, Dec 12, 2012 at 9:11 AM, Eric Paris <eparis@xxxxxxxxxx> wrote: >> 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 :) > > That's my way of looking at it -- using more than one LSM that uses > attr/current with old userspace lands you in a very confusing place. > E.g. with the current patch, if SELinux is stacked but not presented, > all the SELinux libraries fail closed and I can't SSH in. :) > > I haven't checked to see how the libraries are deciding that SELinux > is built-in (/sys/modules? securityfs?) It feels like trying to use > this kernel feature without userspace support should be considered a > 'bad idea'. :) Building a kernel without stacked (conflicting) LSMs, > everything continues to work fine. > > -Kees > > -- > Kees Cook > Chrome OS Security > -- > To unsubscribe from this list: send the line "unsubscribe linux-security-module" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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.
