Bug 1265266

Summary: SELinux not allowing rpcbind to do a chown on /run
Product: Red Hat Enterprise Linux 7 Reporter: Steve Dickson <steved>
Component: selinux-policyAssignee: Lukas Vrabec <lvrabec>
Status: CLOSED ERRATA QA Contact: Karel Srot <ksrot>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.2CC: ksrot, lvrabec, mgrepl, mmalik, plautrba, pvrabec, ssekidde, steved, tlavigne, yoyang
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: selinux-policy-3.13.1-54.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-19 10:46:35 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1240817    
Attachments:
Description Flags
The audit.log
none
restorecon -R -v / 2>&1 | tee /tmp/restorecon.log
none
ausearch -m AVC 2>&1 | tee /tmp/ausearch.log none

Description Steve Dickson 2015-09-22 13:54:55 UTC
Created attachment 1075850 [details]
The audit.log

Description of problem:
With RHEL7.2 rpcbind is trying to create a couple files 
under /run. Selinux allows rpcbind to create the files
but not change the owner/group of the files. 

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. upgrade to the latest rpcbind package
2.
3.


Additional info:
A suggested have been;

-allow rpcbind_t self:capability { dac_override setgid setuid
sys_tty_config };
+allow rpcbind_t self:capability { dac_override chown setgid setuid
sys_tty_config };

Comment 1 Steve Dickson 2015-09-23 12:34:46 UTC
Created attachment 1076190 [details]
restorecon -R -v /  2>&1 | tee /tmp/restorecon.log

Comment 2 Steve Dickson 2015-09-23 12:37:05 UTC
Created attachment 1076192 [details]
ausearch -m AVC 2>&1 | tee /tmp/ausearch.log

Comment 4 Karel Srot 2015-10-07 19:52:32 UTC
Hi Steve,
what commands do I need to run in order to get those AVC denials?

Comment 10 Steve Dickson 2015-10-12 08:46:30 UTC
(In reply to Karel Srot from comment #4)
> Hi Steve,
> what commands do I need to run in order to get those AVC denials?

systemctl start rpcbind # This will cause the /run/rpcbind to be 
  created as root. Then rpcbind changes uid/gid to rpc. So to 
  make /run/rpcbind write-able when rpcbind exits /run/rpcbind
  has to be chown to rpc, before changing id. The chown is failing.

Comment 11 Milos Malik 2015-10-12 08:58:41 UTC
Good catch!

# rpm -qf /run/rpcbind
file /run/rpcbind is not owned by any package
#

Comment 12 Milos Malik 2015-10-12 09:12:04 UTC
Following messages appear in /var/log/messages, when the /run/rpcbind directory does not exist:

Oct 12 11:09:49 rhel71 rpcbind: cannot open file = /run/rpcbind/rpcbind.xdr for writing
Oct 12 11:09:49 rhel71 rpcbind: cannot save any registration
Oct 12 11:09:49 rhel71 rpcbind: cannot open file = /run/rpcbind/portmap.xdr for writing
Oct 12 11:09:49 rhel71 rpcbind: cannot save any registration
Oct 12 11:09:49 rhel71 systemd: Stopping RPC bind service...
Oct 12 11:09:49 rhel71 systemd: Stopped RPC bind service.

Comment 13 Karel Srot 2015-10-12 09:44:40 UTC
(In reply to Steve Dickson from comment #10)
> (In reply to Karel Srot from comment #4)
> > Hi Steve,
> > what commands do I need to run in order to get those AVC denials?
> 
> systemctl start rpcbind # This will cause the /run/rpcbind to be 
>   created as root. Then rpcbind changes uid/gid to rpc. So to 
>   make /run/rpcbind write-able when rpcbind exits /run/rpcbind
>   has to be chown to rpc, before changing id. The chown is failing.

In my case /run/rpcbind is not created at all, despite I have the selinux-policy containing the proposed update. And it is not happening due to selinux (I am running with permissive).

In /var/log/messages I can see lines from #c12.

Comment 18 Steve Dickson 2015-10-13 19:43:05 UTC
(In reply to Milos Malik from comment #11)
> Good catch!
> 
> # rpm -qf /run/rpcbind
> file /run/rpcbind is not owned by any package
> #

Why does a cache area have to be owned by a package?

Comment 19 Steve Dickson 2015-10-13 19:44:48 UTC
(In reply to Milos Malik from comment #12)
> Following messages appear in /var/log/messages, when the /run/rpcbind
> directory does not exist:
> 
> Oct 12 11:09:49 rhel71 rpcbind: cannot open file = /run/rpcbind/rpcbind.xdr
> for writing
> Oct 12 11:09:49 rhel71 rpcbind: cannot save any registration
> Oct 12 11:09:49 rhel71 rpcbind: cannot open file = /run/rpcbind/portmap.xdr
> for writing
> Oct 12 11:09:49 rhel71 rpcbind: cannot save any registration
> Oct 12 11:09:49 rhel71 systemd: Stopping RPC bind service...
> Oct 12 11:09:49 rhel71 systemd: Stopped RPC bind service.

did this happen after the upgrade?

Has it happen again?

Comment 21 Milos Malik 2015-10-14 07:51:42 UTC
If /run/rpcbind is not owned by any package then I expect that the directory will be created during the service start or stop, but it does not happen on RHEL-7.2. Therefore we see the error messages in /var/log/messages every time.

If /run/rpcbind was owned by a package then "rpm -V rpcbind" would tell us that the directory does not exist or that it has different UID / GID / permissions set.

# ls -l /run/rpcbind
ls: cannot access /run/rpcbind: No such file or directory
# service rpcbind start
Redirecting to /bin/systemctl start  rpcbind.service
# service rpcbind status
Redirecting to /bin/systemctl status  rpcbind.service
● rpcbind.service - RPC bind service
   Loaded: loaded (/usr/lib/systemd/system/rpcbind.service; indirect; vendor preset: enabled)
   Active: active (running) since Wed 2015-10-14 09:22:42 CEST; 10min ago
  Process: 3393 ExecStart=/sbin/rpcbind -w ${RPCBIND_ARGS} (code=exited, status=0/SUCCESS)
 Main PID: 3394 (rpcbind)
   CGroup: /system.slice/rpcbind.service
           └─3394 /sbin/rpcbind -w

Oct 14 09:22:42 rhel72.localdomain systemd[1]: Starting RPC bind service...
Oct 14 09:22:42 rhel72.localdomain systemd[1]: Started RPC bind service.
Oct 14 09:33:25 rhel72.localdomain systemd[1]: Started RPC bind service.
# service rpcbind stop
Redirecting to /bin/systemctl stop  rpcbind.service
Warning: Stopping rpcbind.service, but it can still be activated by:
  rpcbind.socket
# ps -efZ | grep rpcbind
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 5121 2326  0 09:33 pts/0 00:00:00 grep --color=auto rpcbind
# ls -l /run/rpcbind
ls: cannot access /run/rpcbind: No such file or directory
# tail /var/log/messages
Oct 14 09:30:11 rhel72 systemd: Stopping user-986.slice.
Oct 14 09:33:25 rhel72 systemd: Started RPC bind service.
Oct 14 09:33:31 rhel72 systemd: Stopping NIS/YP (Network Information Service) Server...
Oct 14 09:33:31 rhel72 systemd: Stopped NIS/YP (Network Information Service) Server.
Oct 14 09:33:31 rhel72 rpcbind: cannot open file = /run/rpcbind/rpcbind.xdr for writing
Oct 14 09:33:31 rhel72 rpcbind: cannot save any registration
Oct 14 09:33:31 rhel72 rpcbind: cannot open file = /run/rpcbind/portmap.xdr for writing
Oct 14 09:33:31 rhel72 rpcbind: cannot save any registration
Oct 14 09:33:31 rhel72 systemd: Stopping RPC bind service...
Oct 14 09:33:31 rhel72 systemd: Stopped RPC bind service.
# 

Switching SELinux to permissive mode does not help here. The /run/rpcbind directory still does not exist after repeating the scenario.

Comment 22 Steve Dickson 2015-10-14 13:18:50 UTC
The /run/rpcbind directory should be created by systemd tmpfiles service.

The /usr/lib/tmpfiles.d/rpcbind.conf should exist and contain the following:
#Type Path         Mode  UID  GID Age Argument
D     /run/rpcbind 0700  rpc  rpc  -  -

The /usr/lib/systemd/system/rpcbind.service file should have the following:
After=systemd-tmpfiles-setup.service

which means the directory should be create before the rpcbind service is started.

What piece of this puzzle is missing?

Comment 23 Milos Malik 2015-10-14 15:27:36 UTC
Based on AVCs listed in attachments, rpcbind was not able to read / write files rpcbind.xdr and portmap.xdr, because they had incorrect label var_run_t. The correct labels are:

# matchpathcon /run/rpcbind
/run/rpcbind	system_u:object_r:rpcbind_var_run_t:s0
# matchpathcon /run/rpcbind/rpcbind.xdr
/run/rpcbind/rpcbind.xdr	system_u:object_r:rpcbind_var_run_t:s0
#

The question is why did they have incorrect labels?

Comment 24 Karel Srot 2015-10-14 16:21:17 UTC
And still I do not understand why the chown cappability is needed. I tried the scenario with selinux-policy dowgraded to a version that doesn't contain/allow this permission and it also worked properly (xdr files were created).

Comment 25 Steve Dickson 2015-10-14 18:51:37 UTC
(In reply to Karel Srot from comment #24)
> And still I do not understand why the chown cappability is needed. I tried
> the scenario with selinux-policy dowgraded to a version that doesn't
> contain/allow this permission and it also worked properly (xdr files were
> created).

So as not run as root, rpcbind changes is uid/gid to rpc/rpc. 
which is the reason rpc is the UID/GID in the systemd-tmpfiles
file (/usr/lib/tmpfiles.d/rpcbind.conf)

Comment 29 Karel Srot 2015-10-19 06:01:24 UTC
I think I have tracked it to the root cause which is rpcbind postun trigger.

triggerpostun scriptlet (using /bin/sh) -- rpcbind < 0.2.0-29
[ ! -d /run/rpcbind ] && mkdir /run/rpcbind
chown rpc:rpc /run/rpcbind
[ -f /var/lib/rpcbind/rpcbind.xdr ] && \
	mv /var/lib/rpcbind/rpcbind.xdr /run/rpcbind
[ -f /var/lib/rpcbind/portmap.xdr ] && \
	mv /var/lib/rpcbind/portmap.xdr /run/rpcbind

Obviously this trigger creates /run/rpcbind but doesn't do a restorecon on a newly created directory. When the directory is created by systemd it gets proper context. Seems that we have added the chown permission for no reason.

[0 root@rhel test]# rpm -Uvh rpcbind-0.2.0-32.el7.x86_64.rpm
warning: rpcbind-0.2.0-32.el7.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID f21541eb: NOKEY
Preparing...                          ################################# [100%]
Updating / installing...
   1:rpcbind-0.2.0-32.el7             ################################# [ 50%]
Cleaning up / removing...
   2:rpcbind-0.2.0-27.el7             ################################# [100%]
[0 root@rhel test]# ls /run/rpcbind*
/run/rpcbind.lock  /run/rpcbind.sock

/run/rpcbind:
portmap.xdr  rpcbind.xdr
[0 root@rhel test]# ls -Zd /run/rpcbind
drwxr-xr-x. rpc rpc unconfined_u:object_r:var_run_t:s0 /run/rpcbind
[0 root@rhel test]# matchpathcon /run/rpcbind
/run/rpcbind	system_u:object_r:rpcbind_var_run_t:s0

Comment 33 Steve Dickson 2015-10-19 18:45:09 UTC
(In reply to Karel Srot from comment #29)
> I think I have tracked it to the root cause which is rpcbind postun trigger.
> 
> triggerpostun scriptlet (using /bin/sh) -- rpcbind < 0.2.0-29
> [ ! -d /run/rpcbind ] && mkdir /run/rpcbind
> chown rpc:rpc /run/rpcbind
> [ -f /var/lib/rpcbind/rpcbind.xdr ] && \
> 	mv /var/lib/rpcbind/rpcbind.xdr /run/rpcbind
> [ -f /var/lib/rpcbind/portmap.xdr ] && \
> 	mv /var/lib/rpcbind/portmap.xdr /run/rpcbind
> 
> Obviously this trigger creates /run/rpcbind but doesn't do a restorecon on a
> newly created directory. When the directory is created by systemd it gets
> proper context. Seems that we have added the chown permission for no reason.
When the chown was a problem, the rpcbind daemon was creating and
chown-ing directory. Then I discovered systemd-tmpfiles and thought
it made more sense for systemd to manage the directory.

The reason the trigger is needed is for updates. When rpcbind 
is updated it needs to keep its state round. Is there something
that can be added to the trigger to make it more selinux friendly??

Comment 34 Karel Srot 2015-10-20 06:49:31 UTC
(In reply to Steve Dickson from comment #33)
> The reason the trigger is needed is for updates. When rpcbind 
> is updated it needs to keep its state round. Is there something
> that can be added to the trigger to make it more selinux friendly??

You should be calling restorecon -R /run/rpcbind in the end to ensure that both the directory and xdr files have proper SELinux context. 
However I am not sure what is the recommended practice here as it pulls in a dependency on policycoreutils and things has to be done wisely. I found some example here
  https://fedoraproject.org/wiki/SELinux_Policy_Modules_Packaging_Draft#Scriptlets
but I believe Milos or Mirek could also help.

Comment 35 Miroslav Grepl 2015-10-20 08:54:48 UTC
If you need to create it this way, you really need to be sure you fix labeling in postscript using restorecon.

[ -x /sbin/restorecon ] && /sbin/restorecon -R /run/rpcbind

Comment 38 errata-xmlrpc 2015-11-19 10:46:35 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2300.html