On 02/20/2012 02:06 AM, Sven Breuner wrote: > Pádraig Brady wrote on 02/20/2012 12:54 AM: >> On 02/19/2012 10:22 PM, Sven Breuner wrote: >>> Is there maybe another check that could be used to find out if selinux is >>> disabled? (e.g. is_selinux_enabled(3) ) >> >> I'm not sure you could use that. >> Even though it's currently disabled, >> you might be surprised that ls didn't >> indicate selinux attributes as normal. > > Agreed, changing behavior that someone might be relying on wouldn't be good. > So I would say the question is whether someone with disabled selinux would > really rely on ls reporting selinux attributes in the "ls -l" output. > > >>>> Back when I wrote that wrapper, it sounded like 10,"unlabeled" >>>> would happen only with kernels deemed crufty back then (in 2009). >>>> >>>> http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/18378/focus=18384 >>>> >>>> That we're still seeing such syscall traces in 2012... >>> >>> I guess that means it's more or less intended that userspace does get >>> ENODATA or "unlabled" instead of EOPNOTSUPP - to show that the system uses >>> a kernel which is generally selinux compatible, even though selinux is >>> disabled. >> >> In the referenced thread above, there is a 2006 kernel patch >> which seems to remove this "unlabeled" thing. >> Though that doesn't seem to correlate with your testing against >> ~/tmp/ls_20120209. > > The way I understood it, that patch should just avoid storing those > attributes on disk. It wasn't intended to completely remove the existence of > "unlabled". > > $ git show 8aad38752e81d1d4de67e3d8e2524618ce7c9276 > [...] > SELinux always maintains a safe internal label if there is none, so with this > patch, we just stick with that and wait until a policy is loaded before > adding a persistent label on disk. > [...] > > >> I just booted RHEL 6.2 with selinux=0 on the kernel command line, >> so as I could test new files without a context created, and... >> >> getxattr("security.selinux") on existing files on ext4, returns the existing >> attribute >> getxattr("security.selinux") on new files on ext4, returns ENODATA >> getxattr("security.selinux") on new files on tmpfs, returns ENOTSUP >> >> So is this "unlabeled" coming from some really old kernel? >> I thought you were on RHEL 6.2? Actually I went back to your >> original report (I presume also on RHEL 6.2) and saw: >> >> lgetxattr("test", "security.selinux", 0x62d130, 255) = -1 ENODATA (No data >> available) >> >> I.E. "unlabeled" was not returned there either. >> What's changed? > > Seems to be inconsistent. Some of our RHEL 6.x systems return "unlabled" on a > tmpfs: > > a) RHEL 6.1... > $ uname -r > 2.6.32-131.21.1.el6.x86_64 > $ sestatus > SELinux status: disabled > $ mount -t tmpfs none /mnt/tmp > $ touch /mnt/tmp/file > $ strace ls -l /mnt/tmp/file 2>&1 | grep security > lgetxattr("/mnt/tmp/file", "security.selinux", "unlabeled", 255) = 10 > > b) Same "unlabeled" result for another machine with RHEL 6.2 kernel > 2.6.32-220.4.1.el6.x86_64. > > c) But then the third machine with RHEL kernel 2.6.32-220.2.1.el6.x86_64 > shows EOPNOTSUPP in the same tmpfs test case: > $ strace ls -l /mnt/tmp/file 2>&1 | grep security > lgetxattr("/mnt/tmp/file", "security.selinux", 0x623300, 255) = -1 EOPNOTSUPP > (Operation not supported) > > All of these systems are fresh RHEL 6 installs, which never ran on an old > kernel and never had selinux enabled (though that probably shouldn't make a > difference on a tmpfs). > > The fhgfs result in these cases is similar to the tmpfs result: "unlabled" on > machines a/b and EOPNOTSUPP on machine c. > > Strange. The only thing I can conclude from these results is that there is a > difference in the selinux configuration of these machines that is effective > even though selinux is disabled. (Just don't know where to look for that > difference to verify this assumption.) > > If we assume that there is something wrong with machines a/b and all those > systems actually should be returning EOPNOTSUPP in a "normal" setup, then the > current cache implementation would work perfectly fine, of course.
Yep. That's what I'm thinking is appropriate for fhgfs. My kernel is 2.6.32-221 BTW. I thought the difference might be selinux=0 boot param, versus selinux=disabled in /etc/selinux/config, but that's not significant. I notice that mount options can give a default context. Is that being used in your "unlabeled" cases? I.E. are there any *context options present? If you can't spot the difference, then this is a good question for an selinux mailing list I think. cheers, Pádraig.
