Bug 634357
| Summary: | fence_scsi fails to unfence with selinux AVC denials | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Ryan O'Hara <rohara> | ||||||
| Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Milos Malik <mmalik> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | urgent | ||||||||
| Version: | 6.0 | CC: | dwalsh, mgrepl, mmalik, rohara, syeghiay | ||||||
| Target Milestone: | rc | Keywords: | ZStream | ||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | selinux-policy-3.7.19-55.el6 | Doc Type: | Bug Fix | ||||||
| Doc Text: |
When the cluster was configured to use fence_scsi, running the cman startup script or using the "fence_node -U <nodename>" command failed. These updated selinux-policy packages contain updated SELinux rules and add the security file context for the /var/lib/cluster directory, which allows the cluster with fence_scsi enabled to work properly.
|
Story Points: | --- | ||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2011-05-19 11:55:10 UTC | Type: | --- | ||||||
| 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: | 532805, 636489 | ||||||||
| Attachments: |
|
||||||||
Who owns the directory /var/lib/cluster? Are there any other directories under /var/lib or /var/run that we do not know about? Dan, this directory is owned by cman. I am able to reproduce it. So I would add a new label for this dir cluster_var_lib_t and allow rhcs domains to manage this directory. Fixed in selinux-policy-3.7.19-55.el6.noarch. Created attachment 447856 [details]
AVC denials for fence_scsi unfencing in permissive mode.
I ran fence_scsi (unfence) again, this time in permissive mode. Here are the AVC denials I see when running in permissive mode, with the same policy as before.
Ryan, could you test it with selinux-policy-3.7.19-55.el6.noarch policy which has a fix for that. Thanks. (In reply to comment #8) > Ryan, > could you test it with selinux-policy-3.7.19-55.el6.noarch policy which has a > fix for that. Thanks. Yes. I just finished testing. After installing the updated policy, I did the following: % setenforce 1 % fence_tool -Uvv <nodename> Checking the audit.log, the last entry I see is for 'setenforce'. Seems that fence_scsi no longer generates any AVC denials. Excellent.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
When the cluster was configured to use fence_scsi, running the cman startup script or using the "fence_node -U <nodename>" command failed. These updated selinux-policy packages contain updated SELinux rules and add the security file context for the /var/lib/cluster directory, which allows the cluster with fence_scsi enabled to work properly.
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-2011-0526.html |
Created attachment 447574 [details] Example config for 3-node RHEL6 cluster w/fence_scsi Description of problem: The fence_scsi agent fails at cman startup when selinux is enabled. When the cman init script starts, it will call 'fence_node -U <nodename>'. This is referred to as unfencing. If an unfence section exists in cluster.conf, the agent will be called with appropriate parameters (typically "action=on"). With fence_scsi (perl script), we see the following AVCs: type=AVC msg=audit(1284585609.699:38506): avc: denied { write } for pid=12562 comm="fence_scsi" name="cluster" dev=dm-0 ino=523912 scontext=unconfined_u:system_r:fenced_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=dir type=SYSCALL msg=audit(1284585609.699:38506): arch=c000003e syscall=2 success=no exit=-13 a0=1cd6550 a1=241 a2=1b6 a3=309291dd10 items=0 ppid=12546 pid=12562 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=386 comm="fence_scsi" exe="/usr/bin/perl" subj=unconfined_u:system_r:fenced_t:s0 key=(null) Version-Release number of selected component (if applicable): selinux-policy-3.7.19-54.el6.noarch fence-agents-3.0.12-8.el6.x86_64 cman-3.0.12-23.el6.x86_64 How reproducible: Always. Steps to Reproduce: 1. Configure cluster to use fence_scsi. 2. Run 'service cman start' or 'fence_node -U <nodename>', where node is the local node's name. Actual results: AVC denials (see above). Expected results: - no AVCs. - key registered with device(s) - key file created in /var/lib/cluster/fence_scsi.key - output written to logfile, if configured. Additional info: I will attach a same cluster.conf to show how fence_scsi is configured.