Bug 576207 - nfsd causes broken SELinux AVCs
Summary: nfsd causes broken SELinux AVCs
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Eric Paris
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-03-23 14:07 UTC by Enrico Scholz
Modified: 2011-02-14 20:43 UTC (History)
13 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2011-02-14 20:43:55 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Enrico Scholz 2010-03-23 14:07:33 UTC
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

Comment 1 Stephen Smalley 2010-03-25 13:16:13 UTC
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?

Comment 2 Eric Paris 2010-03-25 13:53:26 UTC
which makes us ask, what is the underlying filesystem on the nfs server?

Comment 3 Enrico Scholz 2010-03-25 14:13:19 UTC
It is an ext4 filesystem.  AVC seems to happen after unclean disconnect/reconnect.

Comment 4 Ian Dall 2010-06-10 08:43:16 UTC
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.

Comment 5 Ian Dall 2010-06-10 10:10:06 UTC
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.

Comment 6 Stephen Smalley 2010-06-10 16:59:28 UTC
You can use * instead, e.g.
dontaudit kernel_t unlabeled_t:file *;

but this will merely hide the bug, not fix it.

Comment 7 Ian Dall 2010-06-12 12:59:13 UTC
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.

Comment 8 Arthur Dent 2010-08-26 10:52:49 UTC
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

Comment 9 Eric Paris 2010-10-12 15:13:26 UTC
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.

Comment 10 J. Bruce Fields 2010-10-12 19:24:33 UTC
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.

Comment 11 Enrico Scholz 2010-11-16 15:09:33 UTC
still with kernel-2.6.35.6-48.fc14.x86_64

Comment 13 Kyle McMartin 2010-12-19 06:42:12 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.