Bug 426581

Summary: SELinux nfs and rpc.mountd denials
Product: [Fedora] Fedora Reporter: Anthony Messina <amessina>
Component: selinux-policy-targetedAssignee: Daniel Walsh <dwalsh>
Status: CLOSED CURRENTRELEASE QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: low    
Version: 7CC: steved
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Current Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-03-05 22:17:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Anthony Messina 2007-12-22 15:10:59 UTC
Description of problem:
SELinux, in permissive mode, logs the following denials for nfs and rpc.mountd 
on a fully updated F7 system.

Version-Release number of selected component (if applicable):
selinux-policy-targeted-2.6.4-63.fc7

How reproducible:
Difficult to tell.  It seems that it occurs when a client accesses one of the 
nfs exports.

Actual results:
avc: denied { ioctl } for comm="rpc.mountd" dev=tmpfs egid=0 euid=0 
exe="/usr/sbin/rpc.mountd" exit=0 fsgid=0 fsuid=0 gid=0 items=0 
path="/dev/mapper/control" pid=2825 scontext=system_u:system_r:nfsd_t:s0 
sgid=0 subj=system_u:system_r:nfsd_t:s0 suid=0 tclass=chr_file 
tcontext=system_u:object_r:lvm_control_t:s0 tty=(none) uid=0

This one is not a file system; I'm not sure why rpc.mountd tried to check it.
avc: denied { getattr } for comm="rpc.mountd" dev=tmpfs egid=0 euid=0 
exe="/usr/sbin/rpc.mountd" exit=0 fsgid=0 fsuid=0 gid=0 items=0 
path="/dev/ipmi0" pid=2825 scontext=system_u:system_r:nfsd_t:s0 sgid=0 
subj=system_u:system_r:nfsd_t:s0 suid=0 tclass=chr_file 
tcontext=system_u:object_r:device_t:s0 tty=(none) uid=0

avc: denied { read } for comm="rpc.mountd" dev=tmpfs egid=0 euid=0 
exe="/usr/sbin/rpc.mountd" exit=10 fsgid=0 fsuid=0 gid=0 items=0 name="root" 
pid=2825 scontext=system_u:system_r:nfsd_t:s0 sgid=0 
subj=system_u:system_r:nfsd_t:s0 suid=0 tclass=blk_file 
tcontext=system_u:object_r:fixed_disk_device_t:s0 tty=(none) uid=0

avc: denied { read } for comm="rpc.mountd" dev=tmpfs egid=0 euid=0 
exe="/usr/sbin/rpc.mountd" exit=10 fsgid=0 fsuid=0 gid=0 items=0 name="sdb2" 
pid=2825 scontext=system_u:system_r:nfsd_t:s0 sgid=0 
subj=system_u:system_r:nfsd_t:s0 suid=0 tclass=blk_file 
tcontext=system_u:object_r:fixed_disk_device_t:s0 tty=(none) uid=0

avc: denied { read } for comm="rpc.mountd" dev=tmpfs egid=0 euid=0 
exe="/usr/sbin/rpc.mountd" exit=10 fsgid=0 fsuid=0 gid=0 items=0 name="sdb2" 
pid=2825 scontext=system_u:system_r:nfsd_t:s0 sgid=0 
subj=system_u:system_r:nfsd_t:s0 suid=0 tclass=blk_file 
tcontext=system_u:object_r:fixed_disk_device_t:s0 tty=(none) uid=0

avc: denied { read } for comm="rpc.mountd" dev=tmpfs egid=0 euid=0 
exe="/usr/sbin/rpc.mountd" exit=10 fsgid=0 fsuid=0 gid=0 items=0 name="md0" 
pid=2825 scontext=system_u:system_r:nfsd_t:s0 sgid=0 
subj=system_u:system_r:nfsd_t:s0 suid=0 tclass=blk_file 
tcontext=system_u:object_r:fixed_disk_device_t:s0 tty=(none) uid=0

avc: denied { read } for comm="rpc.mountd" dev=tmpfs egid=0 euid=0 
exe="/usr/sbin/rpc.mountd" exit=10 fsgid=0 fsuid=0 gid=0 items=0 name="sdb1" 
pid=2825 scontext=system_u:system_r:nfsd_t:s0 sgid=0 
subj=system_u:system_r:nfsd_t:s0 suid=0 tclass=blk_file 
tcontext=system_u:object_r:fixed_disk_device_t:s0 tty=(none) uid=0

Expected results:


Additional info:
current nfs settings:
allow_ftpd_use_nfs --> off
allow_nfsd_anon_write --> on
httpd_use_nfs --> off
nfs_export_all_ro --> on
nfs_export_all_rw --> on
samba_share_nfs --> off
use_nfs_home_dirs --> on

and i already tried a restorecon -R -v /dev which only did this:
~#] restorecon -R -v /dev
restorecon reset /dev/shm context 
system_u:object_r:tmpfs_t:s0->system_u:object_r:device_t:s0

Comment 1 Daniel Walsh 2007-12-31 13:29:55 UTC
This looks a lot like a leaked file descriptor.  How did rpc.mountd get
startted?  It is trying to read blk devices and /dev/mapper/control which is
owned by lvm?  So could this be an lvm tool that is launching rpc.mountd and
leaking the file descriprors.

Could you look for processes running as initrc_t?

ps -eZ | grep initrc_t


Comment 2 Anthony Messina 2008-01-02 18:59:00 UTC
~]# ps -eZ | grep initrc_t
system_u:system_r:initrc_t       2219 ?        00:00:01 rpcbind
system_u:system_r:initrc_t       2788 ?        00:00:00 rpc.rquotad
system_u:system_r:initrc_t       3159 ?        00:00:57 postgrey
system_u:system_r:initrc_t       3241 ?        00:01:43 mailgraph
system_u:system_r:initrc_t       3580 ?        00:00:00 faxq
system_u:system_r:initrc_t       3584 ?        00:00:00 hfaxd
system_u:system_r:initrc_t       3602 ?        00:00:00 iaxmodem
system_u:system_r:initrc_t       3603 ?        00:00:00 iaxmodem
system_u:system_r:initrc_t       3707 ?        00:00:00 python
system_u:system_r:initrc_t       3708 ?        00:03:08 python
system_u:system_r:initrc_t       3710 ?        00:03:11 python
system_u:system_r:initrc_t       3712 ?        00:03:07 python
system_u:system_r:initrc_t       3713 ?        00:03:07 python
system_u:system_r:initrc_t       3714 ?        00:03:08 python
system_u:system_r:initrc_t       3715 ?        00:03:12 python
system_u:system_r:initrc_t       3716 ?        00:03:08 python
system_u:system_r:initrc_t       3717 ?        00:00:00 python
root:system_r:initrc_t          15498 ?        00:00:00 safe_asterisk
root:system_r:initrc_t          15503 ?        00:03:32 asterisk
root:system_r:initrc_t          25352 ?        00:00:00 mysqld_safe

Comment 3 Daniel Walsh 2008-01-03 16:04:22 UTC
You have many processes running with the wrong context.  So I believe you have a
major labeling problem.   You can relabel using

fixfiles restore

Or 

touch /.autorelabel; reboot

You will need to reboot to get the processes running with the right context.

Comment 4 Anthony Messina 2008-01-03 18:45:34 UTC
Ok, I did: touch /.autorelabel; reboot.

After which, I have the same processes in initrc_t:

~]# ps -eZ | grep initrc_t
system_u:system_r:initrc_t       2216 ?        00:00:00 rpcbind
system_u:system_r:initrc_t       2785 ?        00:00:00 rpc.rquotad
system_u:system_r:initrc_t       2883 ?        00:00:00 mysqld_safe
system_u:system_r:initrc_t       3159 ?        00:00:00 postgrey
system_u:system_r:initrc_t       3238 ?        00:00:05 mailgraph
system_u:system_r:initrc_t       3311 ?        00:00:00 safe_asterisk
system_u:system_r:initrc_t       3329 ?        00:00:01 asterisk
system_u:system_r:initrc_t       3560 ?        00:00:00 faxq
system_u:system_r:initrc_t       3563 ?        00:00:00 hfaxd
system_u:system_r:initrc_t       3582 ?        00:00:00 iaxmodem
system_u:system_r:initrc_t       3583 ?        00:00:00 iaxmodem
system_u:system_r:initrc_t       3705 ?        00:00:00 python
system_u:system_r:initrc_t       3706 ?        00:00:00 python
system_u:system_r:initrc_t       3707 ?        00:00:00 python
system_u:system_r:initrc_t       3708 ?        00:00:00 python
system_u:system_r:initrc_t       3709 ?        00:00:00 python
system_u:system_r:initrc_t       3710 ?        00:00:00 python
system_u:system_r:initrc_t       3711 ?        00:00:00 python
system_u:system_r:initrc_t       3712 ?        00:00:00 python
system_u:system_r:initrc_t       3713 ?        00:00:00 python

The python processes are mailman qrunners and a Postfix policy daemon for spf.


And some other weirdness...  Every now and then, it seems a file I never tough 
gets changes to public_content_rw_t (usually in /etc or /usr/share), so to 
test which files didn't match their intended contexts immediately after a 
reboot/relabel, I did:

~]# restorecon -R -v -n /

and got:

restorecon reset /dev/shm context 
system_u:object_r:tmpfs_t:s0->system_u:object_r:device_t:s0
restorecon reset /home/amessina/.DCOPserver_linux-ws1.chicago.messinet.com__0 
context system_u:object_r:user_home_dir_t:s0->user_u:object_r:user_home_t:s0
restorecon reset /home/amessina/.gpg-agent-info context 
system_u:object_r:user_home_dir_t:s0->user_u:object_r:user_home_t:s0
restorecon reset /home/amessina/.ICEauthority context 
system_u:object_r:user_home_dir_t:s0->user_u:object_r:user_home_t:s0
restorecon reset /home/amessina/.dmrc context 
system_u:object_r:user_home_dir_t:s0->user_u:object_r:user_home_t:s0
restorecon reset /home/amessina/.xsession-errors context 
system_u:object_r:user_home_dir_t:s0->user_u:object_r:user_home_t:s0
restorecon reset /home/amessina/.DCOPserver_linux-ws1.chicago.messinet.com_:0 
context system_u:object_r:user_home_dir_t:s0->user_u:object_r:user_home_t:s0
restorecon 
reset /export/home/amessina/.DCOPserver_linux-ws1.chicago.messinet.com__0 
context system_u:object_r:user_home_dir_t:s0->user_u:object_r:user_home_t:s0
restorecon reset /export/home/amessina/.gpg-agent-info context 
system_u:object_r:user_home_dir_t:s0->user_u:object_r:user_home_t:s0
restorecon reset /export/home/amessina/.ICEauthority context 
system_u:object_r:user_home_dir_t:s0->user_u:object_r:user_home_t:s0
restorecon reset /export/home/amessina/.dmrc context 
system_u:object_r:user_home_dir_t:s0->user_u:object_r:user_home_t:s0
restorecon reset /export/home/amessina/.xsession-errors context 
system_u:object_r:user_home_dir_t:s0->user_u:object_r:user_home_t:s0
restorecon 
reset /export/home/amessina/.DCOPserver_linux-ws1.chicago.messinet.com_:0 
context system_u:object_r:user_home_dir_t:s0->user_u:object_r:user_home_t:s0
restorecon reset /export/private/lost+found context 
system_u:object_r:lost_found_t:s0->system_u:object_r:default_t:s0
restorecon reset /export/pub/lost+found context 
system_u:object_r:lost_found_t:s0->system_u:object_r:default_t:s0
restorecon reset /var/lock/LCK.. context 
system_u:object_r:apcupsd_lock_t:s0->system_u:object_r:var_lock_t:s0
restorecon reset /var/spool/amavisd/amavisd.sock context 
system_u:object_r:amavis_var_run_t:s0->system_u:object_r:amavis_spool_t:s0
restorecon reset /var/run/asterisk/asterisk.pid context 
system_u:object_r:initrc_var_run_t:s0->system_u:object_r:var_run_t:s0
restorecon reset /var/run/xfs.pid context 
system_u:object_r:xfs_var_run_t:s0->system_u:object_r:var_run_t:s0
restorecon reset /var/run/iaxmodem.pid context 
system_u:object_r:initrc_var_run_t:s0->system_u:object_r:var_run_t:s0
restorecon reset /var/run/smbd.pid context 
system_u:object_r:smbd_var_run_t:s0->system_u:object_r:var_run_t:s0
restorecon reset /var/run/rpcbind.lock context 
system_u:object_r:initrc_var_run_t:s0->system_u:object_r:var_run_t:s0
restorecon reset /var/run/sshd.pid context 
system_u:object_r:sshd_var_run_t:s0->system_u:object_r:var_run_t:s0
restorecon reset /var/run/nmbd.pid context 
system_u:object_r:nmbd_var_run_t:s0->system_u:object_r:var_run_t:s0
restorecon reset /var/run/cyrus-master.pid context 
system_u:object_r:cyrus_var_run_t:s0->system_u:object_r:var_run_t:s0
restorecon reset /var/run/setroubleshootd.pid context 
system_u:object_r:setroubleshoot_var_run_t:s0->system_u:object_r:var_run_t:s0
restorecon reset /var/run/gpm.pid context 
system_u:object_r:gpm_var_run_t:s0->system_u:object_r:var_run_t:s0
restorecon reset /var/run/cupsd.pid context 
system_u:object_r:cupsd_var_run_t:s0->system_u:object_r:var_run_t:s0
restorecon reset /var/run/console-kit-daemon.pid context 
system_u:object_r:consolekit_var_run_t:s0->system_u:object_r:var_run_t:s0
restorecon reset /var/run/sm-notify.pid context 
system_u:object_r:rpcd_var_run_t:s0->system_u:object_r:var_run_t:s0
restorecon reset /var/run/messagebus.pid context 
system_u:object_r:system_dbusd_var_run_t:s0->system_u:object_r:var_run_t:s0
restorecon reset /var/run/mailgraph.pid context 
system_u:object_r:initrc_var_run_t:s0->system_u:object_r:var_run_t:s0
restorecon reset /var/run/amavisd/clamd.pid context 
system_u:object_r:amavis_var_run_t:s0->system_u:object_r:clamd_var_run_t:s0



Comment 5 Daniel Walsh 2008-01-03 19:11:37 UTC
 I did not know rpcbind shipped for FC7?

I guess this all looks ok.  Are you seeing any real failures or just the avc
messages.  

IE Is nfs and rpc.mountd working correctly?

Comment 6 Anthony Messina 2008-01-03 19:20:34 UTC
Things seem to work properly (I have it in permissive mode for now), but even 
after the reboot/relabel, I still get:

avc: denied { read, write } for comm="rpc.mountd" dev=tmpfs egid=0 euid=0 
exe="/usr/sbin/rpc.mountd" exit=9 fsgid=0 fsuid=0 gid=0 items=0 name="control" 
pid=2822 scontext=system_u:system_r:nfsd_t:s0 sgid=0 
subj=system_u:system_r:nfsd_t:s0 suid=0 tclass=chr_file 
tcontext=system_u:object_r:lvm_control_t:s0 tty=(none) uid=0

I don't use lvm, so this is of no matter.  Trouble is, the suggestion is to:

If you want to export file systems using nfs you need to turn on the 
nfs_export_all_ro boolean: "setsebool -P nfs_export_all_ro=1".

The following command will allow this access:
setsebool -P nfs_export_all_ro=1

and I already have that boolean enabled.

Comment 7 Daniel Walsh 2008-01-03 20:31:12 UTC
That is a bug in the plugin. 

The plugin is not looking at the type of the file chr_file.  So it is assuming
that the boolean will fix the problem.  Also setroubleshoot should check the
state of the boolean before suggesting turning it on.  :^)


I have no idea why/rpc.mountd would be trying to read/write /dev/mapper/control
I actually don't believe it is.  I talked to the NFS maintainer and he has no
idea either.   

If you service nfs restart

do you get these avcs?



Comment 8 Anthony Messina 2008-01-05 18:46:07 UTC
yes i do get them if i restart nfs.  but it doesn't seem to affect function.

Comment 9 Daniel Walsh 2008-01-08 18:56:18 UTC
You can allow this for now by executing 

# audit2allow -M mypol -i /var/log/audit/audit.log 
# semodule -i mypol.pp

Fixed in selinux-policy-2.6.4-69.fc7

Comment 10 Daniel Walsh 2008-03-05 22:17:38 UTC
Bugs have been in modified for over one month.  Closing as fixed in current
release please reopen if the problem still persists.