Bug 426581 - SELinux nfs and rpc.mountd denials
SELinux nfs and rpc.mountd denials
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
7
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-22 10:10 EST by Anthony Messina
Modified: 2008-03-05 17:17 EST (History)
1 user (show)

See Also:
Fixed In Version: Current
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-05 17:17:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Anthony Messina 2007-12-22 10:10:59 EST
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 08:29:55 EST
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 13:59:00 EST
~]# 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 11:04:22 EST
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 13:45:34 EST
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 14:11:37 EST
 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 14:20:34 EST
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 15:31:12 EST
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 13:46:07 EST
yes i do get them if i restart nfs.  but it doesn't seem to affect function.
Comment 9 Daniel Walsh 2008-01-08 13:56:18 EST
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 17:17:38 EST
Bugs have been in modified for over one month.  Closing as fixed in current
release please reopen if the problem still persists.

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