Bug 522158 - Create SELinux policy to support running Cluster Suite
Create SELinux policy to support running Cluster Suite
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy (Show other bugs)
5.4
All Linux
urgent Severity urgent
: rc
: ---
Assigned To: Miroslav Grepl
Cluster QE
:
: 503141 (view as bug list)
Depends On:
Blocks: 503141 522159 5.5TechNotes-Updates
  Show dependency treegraph
 
Reported: 2009-09-09 11:47 EDT by Perry Myers
Modified: 2016-04-26 09:42 EDT (History)
27 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 503141
: 522159 (view as bug list)
Environment:
Last Closed: 2010-03-30 03:49:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
audit.log from morph-01 (11.61 KB, text/plain)
2010-02-11 15:21 EST, Nate Straz
no flags Details
audit.log from node 1 as mentioned in Comment #38 (30.47 KB, text/x-log)
2010-02-15 16:40 EST, Brian Likosar
no flags Details
audit.log from node 2 as mentioned in Comment #38 (21.82 KB, text/x-log)
2010-02-15 16:41 EST, Brian Likosar
no flags Details
audit.log from node 3 as mentioned in Comment #38 (20.41 KB, text/x-log)
2010-02-15 16:42 EST, Brian Likosar
no flags Details
Audit logs from morph during rgmanager test (5.56 KB, application/x-gzip)
2010-02-23 09:54 EST, Nate Straz
no flags Details

  None (edit)
Comment 1 Perry Myers 2009-09-09 11:48:24 EDT
Note: dwalsh and ccaulfie have already been working on a selinux policy for use in Fedora.  This bug is to track backporting that policy into RHEL5.
Comment 2 Daniel Walsh 2009-10-15 14:34:32 EDT
Fixed in selinux-policy-2.4.6-260.el5
Comment 3 Elia Pinto 2009-10-16 05:03:58 EDT
When in RHN ?
Comment 4 Daniel Walsh 2009-10-16 09:32:24 EDT
Not until RHEL5.5

Preview is available on 

http://people.redhat.com/dwalsh/SELinux/RHEL5/noarch

Please test and tell us what blows up on you.
Comment 13 Perry Myers 2009-10-22 13:32:12 EDT
*** Bug 503141 has been marked as a duplicate of this bug. ***
Comment 25 Chris Ward 2010-02-11 05:14:00 EST
~~ Attention Customers and Partners - RHEL 5.5 Beta is now available on RHN ~~

RHEL 5.5 Beta has been released! There should be a fix present in this 
release that addresses your request. Please test and report back results 
here, by March 3rd 2010 (2010-03-03) or sooner.

Upon successful verification of this request, post your results and update 
the Verified field in Bugzilla with the appropriate value.

If you encounter any issues while testing, please describe them and set 
this bug into NEED_INFO. If you encounter new defects or have additional 
patch(es) to request for inclusion, please clone this bug per each request
and escalate through your support representative.
Comment 28 Nate Straz 2010-02-11 15:21:16 EST
Created attachment 390340 [details]
audit.log from morph-01

I hit a few AVC messages related to ricci during testing of 
selinux-policy-2.4.6-271.el5.  Attached is the raw log, output of audit2allow is below:

[nstraz@try 1.selinux_check]$ cat morph-0*/audit.msgs.log | audit2allow
allow ricci_modclusterd_t cluster_port_t:tcp_socket name_connect;
allow ricci_modclusterd_t hi_reserved_port_t:tcp_socket name_bind;
allow ricci_modclusterd_t inetd_child_t:unix_stream_socket connectto;
allow ricci_modclusterd_t inetd_t:unix_stream_socket connectto;
allow ricci_modclusterd_t var_run_t:sock_file write;
Comment 29 Daniel Walsh 2010-02-11 15:37:02 EST
What is listening at /var/run/cman_client?


What is running under inetd?
Comment 32 Nate Straz 2010-02-12 11:10:08 EST
(In reply to comment #29)
> What is listening at /var/run/cman_client?

[root@morph-03 kernel]# netstat -xpa | grep cman_client
unix  2      [ ACC ]     STREAM     LISTENING     1499540 21322/aisexec       /var/run/cman_client

[root@morph-03 kernel]# ps -ZC aisexec
LABEL                             PID TTY          TIME CMD
system_u:system_r:inetd_t:SystemLow-SystemHigh 21322 ? 00:16:47 aisexec

Hrm, that shouldn't be running under inetd_t.  It was probably started from qarshd, which is started by xinetd.  Perhaps our qarshd policy isn't loading correctly.
Comment 34 Nate Straz 2010-02-12 11:31:45 EST
Looks like I didn't get the qarshd policy installed or loaded correctly.  Jaroslav straightened me out and I'm back in business.  Sorry about the distraction.
Comment 35 Miroslav Grepl 2010-02-12 11:39:16 EST
(In reply to comment #34)
> Looks like I didn't get the qarshd policy installed or loaded correctly. 
> Jaroslav straightened me out and I'm back in business.  Sorry about the
> distraction.    

Ok.
Comment 36 Jaroslav Kortus 2010-02-12 11:52:52 EST
type=AVC msg=audit(1265993391.961:1114): avc:  denied  { getattr } for  pid=14072 comm="fence_apc" name="/" dev=devpts ino=1 scontext=root:system_r:fenced_t:s0 tcontext=system_u:object_r:devpts_t:s0 tclass=filesystem

Happens during fence event via APC power switch.
Comment 37 Miroslav Grepl 2010-02-15 10:59:22 EST
Fixed in selinux-policy-2.4.6-274.el5
Comment 38 Brian Likosar 2010-02-15 16:36:42 EST
I still receive AVC denials when using conga to configure services with the latest selinux policy enabled.  I'll attach the logs from my three-node cluster.
Comment 39 Brian Likosar 2010-02-15 16:40:30 EST
Created attachment 394411 [details]
audit.log from node 1 as mentioned in Comment #38
Comment 40 Brian Likosar 2010-02-15 16:41:07 EST
Created attachment 394412 [details]
audit.log from node 2 as mentioned in Comment #38
Comment 41 Brian Likosar 2010-02-15 16:42:40 EST
Created attachment 394413 [details]
audit.log from node 3 as mentioned in Comment #38
Comment 42 Miroslav Grepl 2010-02-16 09:16:45 EST
Brian,

did you test it with 

selinux-policy-2.4.6-274.el5 
selinux-policy-targeted-2.4.6-274.el5 

packages?


Also I have sent you a mail with local policy which contains fixes for these errors.

Could you test it ?
Comment 43 Nate Straz 2010-02-18 16:30:47 EST
I hit this while running qdisk tests w/ selinux-policy-2.4.6-274.el5.

type=AVC msg=audit(1266518805.733:814): avc:  denied  { sys_boot } for  pid=10895 comm="qdiskd" capability=22 scontext=system_u:system_r:qdiskd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:qdiskd_t:s0-s0:c0.c1023 tclass=capability

I'm not sure what the qdiskd is trying to do here.
Comment 44 Daniel Walsh 2010-02-18 17:10:15 EST
sys_boot means


/* Allow use of reboot() */

#define CAP_SYS_BOOT         22

So qdiskd_t is trying to reboot the machine.
Comment 45 Daniel Walsh 2010-02-18 17:16:13 EST
Googling for qdiskd and reboot shows

reboot="1"
    If set to 0 (off), qdiskd will *not* reboot after a negative transition as a result in a change in score (see section 2.2). The default for this value is 1 (on). 

So it looks like qdiskd needs this capability.  It is the first domain, I have ever seen that needs this capability directly.

Miroslav can you add it.
Comment 46 Miroslav Grepl 2010-02-19 10:41:11 EST
Brian,
thank you for your testing. 


All fixes are added to selinux-policy-2.4.6-275.el5 together with sys_boot capability.
Comment 47 Nate Straz 2010-02-19 17:20:10 EST
I found this while running against selinux-policy-2.4.6-275.el5

audit.log:

type=AVC msg=audit(1266617758.201:2192): avc:  denied  { read write } for  pid=9746 comm="gfs_controld" name="dlm_plock" dev=tmpfs ino=66038 scontext=system_u:system_r:gfs_controld_t:s0-s0:c0.c1023 tcontext=system_u:object_r:device_t:s0 tclass=chr_file


audit2allow output:

#============= gfs_controld_t ==============
allow gfs_controld_t device_t:chr_file { read write getattr };
Comment 48 Nate Straz 2010-02-19 17:40:22 EST
Here are a few more log entries from fence_apc accessing /proc/meminfo.

type=AVC msg=audit(1266618620.473:2892): avc:  denied  { read } for  pid=9813 comm="fence_apc" name="meminfo" dev=proc ino=4026531842 scontext=system_u:system_r:fenced_t:s0-s0:c0.c1023 tcontext=system_u:object_r:proc_t:s0 tclass=file
type=SYSCALL msg=audit(1266618620.473:2892): arch=c000003e syscall=2 success=yes exit=8 a0=3859b20da0 a1=0 a2=1b6 a3=0 items=0 ppid=9490 pid=9813 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="fence_apc" exe="/usr/bin/python" subj=system_u:system_r:fenced_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1266618620.473:2893): avc:  denied  { getattr } for  pid=9813 comm="fence_apc" path="/proc/meminfo" dev=proc ino=4026531842 scontext=system_u:system_r:fenced_t:s0-s0:c0.c1023 tcontext=system_u:object_r:proc_t:s0 tclass=file
type=SYSCALL msg=audit(1266618620.473:2893): arch=c000003e syscall=5 success=yes exit=0 a0=8 a1=7fff62714aa0 a2=7fff62714aa0 a3=0 items=0 ppid=9490 pid=9813 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="fence_apc" exe="/usr/bin/python" subj=system_u:system_r:fenced_t:s0-s0:c0.c1023 key=(null)


audit2allow output:
#============= fenced_t ==============
allow fenced_t proc_t:file { read getattr };
Comment 49 Daniel Walsh 2010-02-20 08:10:52 EST
What is  /dev/dlm_plock?  Is this the correct path?  We do not have a file context defined for this, so it is labeled device_t which no confined domains have access.

fenced reading proc seems fine.
Comment 50 Daniel Walsh 2010-02-20 08:15:09 EST
We do have 

/dev/misc/dlm.*	-c	system_u:object_r:dlm_control_device_t:s0

Does dlm_plock exist in the /dev/misc directory?
Comment 51 Nate Straz 2010-02-20 08:26:45 EST
Dave,

Can you answer Dan's questions in comments #49 and #50?
Comment 52 Miroslav Grepl 2010-02-22 04:58:06 EST
(In reply to comment #47)
> I found this while running against selinux-policy-2.4.6-275.el5
> 
> audit.log:
> 
> type=AVC msg=audit(1266617758.201:2192): avc:  denied  { read write } for 
> pid=9746 comm="gfs_controld" name="dlm_plock" dev=tmpfs ino=66038
> scontext=system_u:system_r:gfs_controld_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:device_t:s0 tclass=chr_file
> 

Nate,

could you check labeling in the /dev/misc directory?

ls -lZ /dev/misc/
Comment 53 Nate Straz 2010-02-22 09:36:09 EST
[root@morph-04 ~]# ls -lZ /dev/misc
crw-------  root root system_u:object_r:device_t       dlm_clvmd
crw-rw-rw-  root root system_u:object_r:device_t       dlm-control
crw-rw----  root root system_u:object_r:device_t       dlm_plock
crw-rw----  root root system_u:object_r:device_t       lock_dlm_plock
Comment 54 Miroslav Grepl 2010-02-22 10:17:39 EST
(In reply to comment #53)
> [root@morph-04 ~]# ls -lZ /dev/misc
> crw-------  root root system_u:object_r:device_t       dlm_clvmd
> crw-rw-rw-  root root system_u:object_r:device_t       dlm-control
> crw-rw----  root root system_u:object_r:device_t       dlm_plock
> crw-rw----  root root system_u:object_r:device_t       lock_dlm_plock    

Ok, could you try these steps:

# restorecon -Rv /dev/misc
# service cman stop
# modprobe -r lock_dlm dlm 
# service cman start

and then check labels.
Comment 55 Nate Straz 2010-02-22 10:25:00 EST
The labels do come up wrong after the cman init script runs.

[root@west-07 qarsh-selinux-1.25]# ls -lZ /dev/misc
crw-------  root root system_u:object_r:device_t       dlm_clvmd
crw-rw-rw-  root root system_u:object_r:device_t       dlm-control
crw-rw----  root root system_u:object_r:device_t       dlm_plock
crw-rw----  root root system_u:object_r:device_t       lock_dlm_plock
You have new mail in /var/spool/mail/root
[root@west-07 qarsh-selinux-1.25]# restorecon -Rv /dev/misc
restorecon reset /dev/misc/dlm_clvmd context system_u:object_r:device_t:s0->system_u:object_r:dlm_control_device_t:s0
restorecon reset /dev/misc/dlm_plock context system_u:object_r:device_t:s0->system_u:object_r:dlm_control_device_t:s0
restorecon reset /dev/misc/dlm-control context system_u:object_r:device_t:s0->system_u:object_r:dlm_control_device_t:s0
restorecon reset /dev/misc/lock_dlm_plock context system_u:object_r:device_t:s0->system_u:object_r:dlm_control_device_t:s0
[root@west-07 qarsh-selinux-1.25]# ls -lZ /dev/misc
crw-------  root root system_u:object_r:dlm_control_device_t dlm_clvmd
crw-rw-rw-  root root system_u:object_r:dlm_control_device_t dlm-control
crw-rw----  root root system_u:object_r:dlm_control_device_t dlm_plock
crw-rw----  root root system_u:object_r:dlm_control_device_t lock_dlm_plock
[root@west-07 qarsh-selinux-1.25]# service clvmd stop
Stopping clvm:                                             [  OK  ]
[root@west-07 qarsh-selinux-1.25]# service cman stop
Stopping cluster:
   Stopping fencing... done
   Stopping cman... done
   Stopping ccsd... done
   Unmounting configfs... done
                                                           [  OK  ]
[root@west-07 qarsh-selinux-1.25]# modprobe -r lock_dlm
[root@west-07 qarsh-selinux-1.25]# modprobe -r gfs
[root@west-07 qarsh-selinux-1.25]# modprobe -r dlm
[root@west-07 qarsh-selinux-1.25]# service cman start
Starting cluster:
   Loading modules... done
   Mounting configfs... done
   Starting ccsd... done
   Starting cman... done
   Starting daemons... done
   Starting fencing... done
                                                           [  OK  ]
[root@west-07 qarsh-selinux-1.25]# ls -lZ /dev/misc
crw-rw-rw-  root root system_u:object_r:device_t       dlm-control
crw-rw----  root root system_u:object_r:device_t       dlm_plock
crw-rw----  root root system_u:object_r:device_t       lock_dlm_plock
Comment 56 Miroslav Grepl 2010-02-22 10:56:13 EST
That's strange. I am also trying to do these steps and I get the proper label on it.

# ls -lZ /dev/misc/
crw-rw-rw-  root root system_u:object_r:dlm_control_device_t dlm-control
crw-rw----  root root system_u:object_r:dlm_control_device_t dlm_plock
crw-rw----  root root system_u:object_r:dlm_control_device_t lock_dlm_plock
Comment 57 David Teigland 2010-02-22 11:07:21 EST
I don't see anything that uses /dev/dlm_plock, only /dev/misc/dlm_plock.
Comment 58 Nate Straz 2010-02-22 11:34:53 EST
(In reply to comment #56)
> That's strange. I am also trying to do these steps and I get the proper label
> on it.

After installing a new selinux-policy package is a restart required to get it loaded correctly or is there some other procedure to get it loaded?
Comment 60 Daniel Walsh 2010-02-22 12:36:01 EST
Dave, ok.

Nate the policy package will load the policy on update.  No need to reboot or reload it.
Comment 61 Nate Straz 2010-02-22 12:40:33 EST
(In reply to comment #60)
> Nate the policy package will load the policy on update.  No need to reboot or
> reload it.    

Is there a way to verify that the new policy is in effect?
Comment 62 Daniel Walsh 2010-02-22 13:51:03 EST
Well you can execute load_policy.  But unless you saw an error on update it should be running.

You could reinstall the selinux-policy-targeted package

yum reinstall selinux-policy-targeted
Comment 63 Tom Lanyon 2010-02-22 17:23:30 EST
Will the policy version shown by 'sestatus' increment with the new policy loaded?
Comment 64 Daniel Walsh 2010-02-22 17:37:42 EST
No that just shows the policy kernel version.

We just rely on rpm for the version.
Comment 65 Nate Straz 2010-02-23 09:54:56 EST
Created attachment 395733 [details]
Audit logs from morph during rgmanager test

Looks like rgmanager is going to be a big mine field when it comes to SE Linux integration.  Here is the audit logs from trying to do HA-NFS with rgmanager.

[nstraz@try t]$ cat audit-morph*.log | audit2allow
allow rgmanager_t file_t:dir { create setattr };
allow rgmanager_t fixed_disk_device_t:blk_file { ioctl read };
allow rgmanager_t kernel_t:process sigkill;
allow rgmanager_t mnt_t:dir { add_name create write };
allow rgmanager_t self:capability { dac_override sys_resource };
allow rgmanager_t var_lib_nfs_t:file { relabelfrom relabelto };
allow rpcd_t rgmanager_tmp_t:dir { add_name create read remove_name write };
allow rpcd_t rgmanager_tmp_t:file { read rename unlink write };
Comment 66 Miroslav Grepl 2010-02-23 11:06:50 EST
Nate, 

what resource script are you testing ?
Comment 67 Nate Straz 2010-02-23 11:28:34 EST
We're using ip, fs, clusterfs, nfsexport, and nfsclient.
Comment 68 Daniel Walsh 2010-02-23 11:56:49 EST
I think we should add the access we have round and then make rgmanager an unconfined domain.
Comment 69 Miroslav Grepl 2010-02-23 12:47:32 EST
Yes, I agree.

Fixed in selinux-policy-2.4.6-277.el5
Comment 72 errata-xmlrpc 2010-03-30 03:49:13 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2010-0182.html

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