Description of problem: After upgrading to Fedora 13 snapshot, I see | type=1400 audit(1269351912.893:17): avc: denied { 0x400000 } for pid=2169 comm="nfsd" name="" dev=dm-17 ino=5685852 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file messages which are a bug accordingly IRC. My setup on server: | $ ps | rpc.mountd -p 892 --no-nfs-version 1 --no-nfs-version 2 | $ cat /etc/exports | /srv/sysroots 192.168.0.0/255.255.0.0(ro,async,no_root_squash) and on client: | nfsroot=192.168.3.24:/srv/sysroots/omap/beagle-ac97,v3,tcp,nolock ip=:::::eth0: kernel cmdline (nfsroot + dhcp autoconf, kernel 2.6.33) AVC was triggered by a read access to filesystem on client (e.g. 'ls'). The mentioned inode is the /srv/sysroots/omap directory which is labeled as | drwxr-xr-x. ensc ensc unconfined_u:object_r:build_file_t:s0 beagle-ac97 Version-Release number of selected component (if applicable): kernel-2.6.33-1.fc13.x86_64 nfs-utils-1.2.1-17.fc13.x86_64
Implication is that the inode was never set up by SELinux and thus has unlabeled_t context/sid and default tclass (file), but is actually a dir (DIR__OPEN is the permission check there). Normally happens upon d_instantiate and friends. Are we missing a security_d_instantiate() hook call somewhere?
which makes us ask, what is the underlying filesystem on the nfs server?
It is an ext4 filesystem. AVC seems to happen after unclean disconnect/reconnect.
This is a very annoying bug! As far as I can tell, everything continues to work, but I get a huge number of log entries. I have tried an "audit2allow" but is gets a parse error.
Also attempting to suppress the audits fails: Compiling targeted localnfs module /usr/bin/checkmodule: loading policy configuration from tmp/localnfs.tmp localnfs.te":37:ERROR 'syntax error' at token '0' on line 1052: dontaudit kernel_t unlabeled_t:file { 0x400000 }; Apparently 0x400000 is not allowed.
You can use * instead, e.g. dontaudit kernel_t unlabeled_t:file *; but this will merely hide the bug, not fix it.
Thanks for that. Hiding is a significant benefit! Earlier (comment #4) I said that everything continues to work, but now I don't think this is true. I see a bunch of unexplained "stale file handle" unless I set selinux state to permisive.
I just wanted to add a "me too" entry to this bug. After a recent upgrade to F13 (also on an ext4 FS) I get exactly the same symptoms (including occasional "stale file handle" errors) and the same messages in the log (hundreds of them). I wasn't aware of the existence of this bug until Dominick Grift pointed me to it after a posting on the selinux mailing list: http://lists.fedoraproject.org/pipermail/selinux/2010-August/012902.html
Adding bruce, the nfsd maintainer. Bruce, comment #1 and #2 indicate the problem and likely reason for the problem. I wonder if this isn't similar to the IMA issue at it's core (BZ 633540) I really should do my own digging, but figured you might know it off the top of your head.
So, if I understand right: 1) the rule is that any time a directory lookup results in creating a new positive dentry, security_d_instantiate() should be called, and 2) we believe that didn't happen in this case? The place where nfsd is most likely to be unusual is when looking up a directory by filehandle; so exporfs_decode_fh() and reconnect_path() would be good places to start looking. I wouldn't be at all surprised if they're doing the wrong thing.
still with kernel-2.6.35.6-48.fc14.x86_64
http://marc.info/?l=linux-fsdevel&m=129013218025665&2=2
Thanks, merged for the next upload of F-13/14/rawhide. I'll update the patch if there's any changes between now and merging.