Bug 1136396

Summary: selinux-policy prevents openafs-1.6 fileserver from starting
Product: Red Hat Enterprise Linux 6 Reporter: Jan Iven <jan.iven>
Component: selinux-policyAssignee: Lukas Vrabec <lvrabec>
Status: CLOSED ERRATA QA Contact: Milos Malik <mmalik>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.5CC: dwalsh, jan.iven, lvrabec, mgrepl, mmalik
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: selinux-policy-3.7.19-270.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1192338 (view as bug list) Environment:
Last Closed: 2015-07-22 07:08:25 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:

Description Jan Iven 2014-09-02 13:33:40 UTC
Description of problem:

openafs-1.6 has new "demand-attached" fileserver binary (and related - salvager, volserver) that are not part of the afs.pp Selinux policy. As a consequence, the AFS main server daemon (bosserver, runs as 'afs_bosserver_exec_t') has no permissions on these binaries and cannot start them.

The policy seems to handle the non-demand-attached servers OK, suggest to use the same fcontext.

Unclear in how far redhat cares/supports this, but since the "afs.pp" policy file is part of the distribution (and causes the issue by making these programs run in their own context), it probably ought to be updated..



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

selinux-policy-3.7.19-231.el6_5.3.noarch

How reproducible:
always

Steps to Reproduce:
1. install openafs-server RPM, e.g from http://openafs.org/release/1.6.9/index-rhel6.html
2. service openafs start
3. /usr/bin/bos create -server localhost -localauth -instance dafs -type dafs -cmd \
    "/usr/afs/bin/dafileserver -L -d 1" \
    "/usr/afs/bin/davolserver -d 1"\
    /usr/afs/bin/salvageserver \
    /usr/afs/bin/dasalvager

 (not sure whether any configuration is required for this test - the above is the set of commands usually running on an AFS fileserver)


Actual results:

Command fails.

Expected results:

Should succeed

Additional info:

# ls -lZ /usr/afs/bin/da*

-rwxr-xr-x. root root system_u:object_r:bin_t:s0       dafileserver
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       dafssync-debug
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       dasalvager
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       davolserver

Workaround:

# semanage fcontext -a -t afs_fsserver_exec_t "/usr/afs/bin/dafileserver" 
# semanage fcontext -a -t afs_fsserver_exec_t "/usr/afs/bin/davolserver"
# semanage fcontext -a -t afs_fsserver_exec_t "/usr/afs/bin/salvageserver"
# semanage fcontext -a -t afs_fsserver_exec_t "/usr/afs/bin/dasalvager"
# fixfiles restore /usr/afs/bin/dafileserver /usr/afs/bin/davolserver /usr/afs/bin/salvageserver /usr/afs/bin/dasalvager
# ls -lZ /usr/afs/bin/dafileserver /usr/afs/bin/davolserver /usr/afs/bin/salvageserver /usr/afs/bin/dasalvager
-rwxr-xr-x. root root system_u:object_r:afs_fsserver_exec_t:s0 /usr/afs/bin/dafileserver
-rwxr-xr-x. root root system_u:object_r:afs_fsserver_exec_t:s0 /usr/afs/bin/dasalvager
-rwxr-xr-x. root root system_u:object_r:afs_fsserver_exec_t:s0 /usr/afs/bin/davolserver
-rwxr-xr-x. root root system_u:object_r:afs_fsserver_exec_t:s0 /usr/afs/bin/salvageserver


Additionally, need some more policy changes (as per audit2allow)

allow afs_bosserver_t urandom_device_t:chr_file read;
allow afs_fsserver_t urandom_device_t:chr_file read;
allow afs_fsserver_t nscd_var_run_t:dir search;
allow afs_fsserver_t self:unix_stream_socket connectto;
allow afs_fsserver_t nscd_t:nscd { getserv shmemserv shmemhost };
allow afs_fsserver_t nscd_t:unix_stream_socket connectto;
allow afs_fsserver_t nscd_var_run_t:file read;
allow afs_fsserver_t nscd_var_run_t:sock_file write;

# this one is less clear - bosserver will try to create /usr/afs/db (and refuse to start if it cannot) - that directory perhaps should instead be shipped via RPM? or assign different context to /usr/afs

allow afs_bosserver_t usr_t:dir { write create add_name };

# and access to /vice*
allow afs_fsserver_t file_t:dir { write search read create open getattr add_name };

Comment 2 Miroslav Grepl 2014-09-03 10:17:42 UTC
(In reply to Jan Iven from comment #0)
> Description of problem:
> 
> openafs-1.6 has new "demand-attached" fileserver binary (and related -
> salvager, volserver) that are not part of the afs.pp Selinux policy. As a
> consequence, the AFS main server daemon (bosserver, runs as
> 'afs_bosserver_exec_t') has no permissions on these binaries and cannot
> start them.
> 
> The policy seems to handle the non-demand-attached servers OK, suggest to
> use the same fcontext.
> 
> Unclear in how far redhat cares/supports this, but since the "afs.pp" policy
> file is part of the distribution (and causes the issue by making these
> programs run in their own context), it probably ought to be updated..
> 
> 
> 
> Version-Release number of selected component (if applicable):
> 
> selinux-policy-3.7.19-231.el6_5.3.noarch
> 
> How reproducible:
> always
> 
> Steps to Reproduce:
> 1. install openafs-server RPM, e.g from
> http://openafs.org/release/1.6.9/index-rhel6.html
> 2. service openafs start
> 3. /usr/bin/bos create -server localhost -localauth -instance dafs -type
> dafs -cmd \
>     "/usr/afs/bin/dafileserver -L -d 1" \
>     "/usr/afs/bin/davolserver -d 1"\
>     /usr/afs/bin/salvageserver \
>     /usr/afs/bin/dasalvager
> 
>  (not sure whether any configuration is required for this test - the above
> is the set of commands usually running on an AFS fileserver)
> 
> 
> Actual results:
> 
> Command fails.
> 
> Expected results:
> 
> Should succeed
> 
> Additional info:
> 
> # ls -lZ /usr/afs/bin/da*
> 
> -rwxr-xr-x. root root system_u:object_r:bin_t:s0       dafileserver
> -rwxr-xr-x. root root system_u:object_r:bin_t:s0       dafssync-debug
> -rwxr-xr-x. root root system_u:object_r:bin_t:s0       dasalvager
> -rwxr-xr-x. root root system_u:object_r:bin_t:s0       davolserver
> 
> Workaround:
> 
> # semanage fcontext -a -t afs_fsserver_exec_t "/usr/afs/bin/dafileserver" 
> # semanage fcontext -a -t afs_fsserver_exec_t "/usr/afs/bin/davolserver"
> # semanage fcontext -a -t afs_fsserver_exec_t "/usr/afs/bin/salvageserver"
> # semanage fcontext -a -t afs_fsserver_exec_t "/usr/afs/bin/dasalvager"
> # fixfiles restore /usr/afs/bin/dafileserver /usr/afs/bin/davolserver
> /usr/afs/bin/salvageserver /usr/afs/bin/dasalvager
> # ls -lZ /usr/afs/bin/dafileserver /usr/afs/bin/davolserver
> /usr/afs/bin/salvageserver /usr/afs/bin/dasalvager
> -rwxr-xr-x. root root system_u:object_r:afs_fsserver_exec_t:s0
> /usr/afs/bin/dafileserver
> -rwxr-xr-x. root root system_u:object_r:afs_fsserver_exec_t:s0
> /usr/afs/bin/dasalvager
> -rwxr-xr-x. root root system_u:object_r:afs_fsserver_exec_t:s0
> /usr/afs/bin/davolserver
> -rwxr-xr-x. root root system_u:object_r:afs_fsserver_exec_t:s0
> /usr/afs/bin/salvageserver
> 
> 
> Additionally, need some more policy changes (as per audit2allow)
> 
> allow afs_bosserver_t urandom_device_t:chr_file read;
> allow afs_fsserver_t urandom_device_t:chr_file read;
> allow afs_fsserver_t nscd_var_run_t:dir search;
> allow afs_fsserver_t self:unix_stream_socket connectto;
> allow afs_fsserver_t nscd_t:nscd { getserv shmemserv shmemhost };
> allow afs_fsserver_t nscd_t:unix_stream_socket connectto;
> allow afs_fsserver_t nscd_var_run_t:file read;
> allow afs_fsserver_t nscd_var_run_t:sock_file write;

Needs to be added.

> 
> # this one is less clear - bosserver will try to create /usr/afs/db (and
> refuse to start if it cannot) - that directory perhaps should instead be
> shipped via RPM? or assign different context to /usr/afs
> 
> allow afs_bosserver_t usr_t:dir { write create add_name };

Yes, there needs to be labeling for /usr/afs.
> 
> # and access to /vice*
> allow afs_fsserver_t file_t:dir { write search read create open getattr
> add_name };

You need to fix/add a labeling for /vice directory.

Comment 3 Miroslav Grepl 2014-09-03 11:38:52 UTC
So do these binaries come from rpm?

rpm -qf /usr/afs/bin/dafileserver

Comment 4 Jan Iven 2014-09-03 12:13:42 UTC
Yes:

~$ rpm -qlp http://openafs.org/dl/openafs/1.6.9/rhel6/x86_64/openafs-server-1.6.9-1.el6.x86_64.rpm | grep /usr/afs/bin/dafileserver
/usr/afs/bin/dafileserver

Comment 5 Miroslav Grepl 2014-09-04 09:13:16 UTC
Ok, thank you for your info.

Comment 6 Lukas Vrabec 2015-03-03 16:41:02 UTC
commit 3d29bb029b1e8403efd8b3b23520d2798417dde8
Author: Lukas Vrabec <lvrabec>
Date:   Tue Mar 3 17:38:01 2015 +0100

    Update afs policy. BZ(1136396)

Comment 8 Milos Malik 2015-05-22 19:21:54 UTC
:: [   INFO   ] :: checking rule 'allow afs_fsserver_t afs_fsserver_t : unix_stream_socket { connectto }'
:: [   FAIL   ] ::   check permission 'connectto' is present (Assert: '1' should equal '0')

Are permissions connectto and connect equivalent?

Comment 10 errata-xmlrpc 2015-07-22 07:08:25 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-1375.html