Hide Forgot
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.
Fixed in selinux-policy-2.4.6-260.el5
When in RHN ?
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.
*** Bug 503141 has been marked as a duplicate of this bug. ***
~~ 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.
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;
What is listening at /var/run/cman_client? What is running under inetd?
(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.
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.
(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.
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.
Fixed in selinux-policy-2.4.6-274.el5
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.
Created attachment 394411 [details] audit.log from node 1 as mentioned in Comment #38
Created attachment 394412 [details] audit.log from node 2 as mentioned in Comment #38
Created attachment 394413 [details] audit.log from node 3 as mentioned in Comment #38
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 ?
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.
sys_boot means /* Allow use of reboot() */ #define CAP_SYS_BOOT 22 So qdiskd_t is trying to reboot the machine.
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.
Brian, thank you for your testing. All fixes are added to selinux-policy-2.4.6-275.el5 together with sys_boot capability.
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 };
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 };
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.
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?
Dave, Can you answer Dan's questions in comments #49 and #50?
(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/
[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
(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.
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
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
I don't see anything that uses /dev/dlm_plock, only /dev/misc/dlm_plock.
(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?
Dave, ok. Nate the policy package will load the policy on update. No need to reboot or reload it.
(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?
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
Will the policy version shown by 'sestatus' increment with the new policy loaded?
No that just shows the policy kernel version. We just rely on rpm for the version.
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 };
Nate, what resource script are you testing ?
We're using ip, fs, clusterfs, nfsexport, and nfsclient.
I think we should add the access we have round and then make rgmanager an unconfined domain.
Yes, I agree. Fixed in selinux-policy-2.4.6-277.el5
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