Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 733513

Summary: New AVCs when starting cman service
Product: Red Hat Enterprise Linux 6 Reporter: Nate Straz <nstraz>
Component: clusterAssignee: Fabio Massimo Di Nitto <fdinitto>
Status: CLOSED DUPLICATE QA Contact: Cluster QE <mspqa-list>
Severity: medium Docs Contact:
Priority: high    
Version: 6.2CC: ccaulfie, cluster-maint, lhh, mmalik, rpeterso, teigland
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-09-06 12:14:36 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:

Description Nate Straz 2011-08-25 20:37:34 UTC
Description of problem:

Here are some new AVC messages that showed up since RHEL 6.1.  I can't tell what is causing them so I'm starting this assigned to cluster.  I need cluster-devel to explain where these are coming from so you can explain what is going on to selinux-devel.


type=DAEMON_START msg=audit(1314304067.268:5184): auditd start, ver=2.1.3 format=raw kernel=2.6.32-191.el6.x86_64 auid=4294967295 pid=9749 subj=system_u:system_r:auditd_t:s0 res=success
type=CONFIG_CHANGE msg=audit(1314304067.386:3431): audit_backlog_limit=320 old=320 auid=4294967295 ses=4294967295 subj=system_u:system_r:auditctl_t:s0 res=1
type=AVC msg=audit(1314304096.798:3432): avc:  denied  { execute } for  pid=9924 comm="find" name="fence_scsi_check.pl" dev=dm-0 ino=787123 scontext=unconfined_u:system_r:corosync_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file
type=SYSCALL msg=audit(1314304096.798:3432): arch=c000003e syscall=21 success=yes exit=0 a0=a2cd58 a1=1 a2=7fff35303ab0 a3=100 items=0 ppid=9923 pid=9924 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=302 comm="find" exe="/bin/find" subj=unconfined_u:system_r:corosync_t:s0 key=(null)
type=AVC msg=audit(1314304096.848:3433): avc:  denied  { getattr } for  pid=9938 comm="ls" path="/usr/sbin/fence_node" dev=dm-0 ino=269206 scontext=unconfined_u:system_r:corosync_t:s0 tcontext=system_u:object_r:fenced_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1314304096.848:3433): arch=c000003e syscall=4 success=yes exit=0 a0=7fff199b5df9 a1=180f010 a2=180f010 a3=1b items=0 ppid=9920 pid=9938 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=302 comm="ls" exe="/bin/ls" subj=unconfined_u:system_r:corosync_t:s0 key=(null)
type=AVC msg=audit(1314304096.918:3434): avc:  denied  { relabelfrom } for  pid=9952 comm="cp" name="cluster.rng" dev=dm-0 ino=791219 scontext=unconfined_u:system_r:corosync_t:s0 tcontext=unconfined_u:object_r:cluster_var_lib_t:s0 tclass=file
type=AVC msg=audit(1314304096.918:3434): avc:  denied  { relabelto } for  pid=9952 comm="cp" name="cluster.rng" dev=dm-0 ino=791219 scontext=unconfined_u:system_r:corosync_t:s0 tcontext=unconfined_u:object_r:cluster_var_lib_t:s0 tclass=file
type=SYSCALL msg=audit(1314304096.918:3434): arch=c000003e syscall=190 success=yes exit=0 a0=4 a1=7fffb58a0900 a2=187f460 a3=2b items=0 ppid=9920 pid=9952 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=302 comm="cp" exe="/bin/cp" subj=unconfined_u:system_r:corosync_t:s0 key=(null)
type=AVC msg=audit(1314304096.919:3435): avc:  denied  { create } for  pid=9952 comm="cp" name="fence_agents.rng.cache" scontext=unconfined_u:system_r:corosync_t:s0 tcontext=system_u:object_r:cluster_var_lib_t:s0 tclass=file
type=SYSCALL msg=audit(1314304096.919:3435): arch=c000003e syscall=2 success=yes exit=4 a0=187f550 a1=c1 a2=180 a3=6165726373662f72 items=0 ppid=9920 pid=9952 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=302 comm="cp" exe="/bin/cp" subj=unconfined_u:system_r:corosync_t:s0 key=(null)
type=AVC msg=audit(1314304096.920:3436): avc:  denied  { relabelfrom } for  pid=9952 comm="cp" name="fence_agents.rng.cache" dev=dm-0 ino=791220 scontext=unconfined_u:system_r:corosync_t:s0 tcontext=system_u:object_r:cluster_var_lib_t:s0 tclass=file
type=AVC msg=audit(1314304096.920:3436): avc:  denied  { relabelto } for  pid=9952 comm="cp" name="fence_agents.rng.cache" dev=dm-0 ino=791220 scontext=unconfined_u:system_r:corosync_t:s0 tcontext=system_u:object_r:cluster_var_lib_t:s0 tclass=file
type=SYSCALL msg=audit(1314304096.920:3436): arch=c000003e syscall=190 success=yes exit=0 a0=4 a1=7fffb58a08c0 a2=187f4a0 a3=27 items=0 ppid=9920 pid=9952 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=302 comm="cp" exe="/bin/cp" subj=unconfined_u:system_r:corosync_t:s0 key=(null)


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


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Nate Straz 2011-08-25 20:43:01 UTC
Version-Release number of selected component (if applicable):

cman-3.0.12.1-13.el6.x86_64
fence-agents-3.1.5-7.el6.x86_64

How reproducible:
Easily

Steps to Reproduce:
1. service cman start

Comment 3 Fabio Massimo Di Nitto 2011-08-26 05:57:12 UTC
I am no selinux expert but by the look of it, I think they are coming from ccs_update_schema that's new in 6.2.

Interesting enough we see AVC only from the fence side of the scan and not the resource-agents bits (ccs_update_schema scans for both at runtime).

What is the general process to get this fixed with selinux-devel guys?

Comment 4 Nate Straz 2011-08-26 13:48:55 UTC
After doing a fresh reinstall I'm coming up with this set of AVCs instead.  


type=AVC msg=audit(1314366345.219:40139): avc:  denied  { execute } for  pid=445 comm="find" name="SAPDatabase" dev=dm-0 ino=1178662 scontext=unconfined_u:system_r:corosync_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file
type=SYSCALL msg=audit(1314366345.219:40139): arch=c000003e syscall=21 success=yes exit=0 a0=a91de8 a1=1 a2=7fff055438c0 a3=100 items=1 ppid=444 pid=445 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="find" exe="/bin/find" subj=unconfined_u:system_r:corosync_t:s0 key=(null)
type=CWD msg=audit(1314366345.219:40139):  cwd="/usr/share/cluster"
type=PATH msg=audit(1314366345.219:40139): item=0 name="SAPDatabase" inode=1178662 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:usr_t:s0
type=AVC msg=audit(1314366345.268:40140): avc:  denied  { getattr } for  pid=459 comm="ls" path="/usr/sbin/fence_node" dev=dm-0 ino=655604 scontext=unconfined_u:system_r:corosync_t:s0 tcontext=system_u:object_r:fenced_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1314366345.268:40140): arch=c000003e syscall=4 success=yes exit=0 a0=7fffd5780df9 a1=ec6010 a2=ec6010 a3=1b items=1 ppid=441 pid=459 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="ls" exe="/bin/ls" subj=unconfined_u:system_r:corosync_t:s0 key=(null)
type=CWD msg=audit(1314366345.268:40140):  cwd="/"
type=PATH msg=audit(1314366345.268:40140): item=0 name="/usr/sbin/fence_node" inode=655604 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:fenced_exec_t:s0
type=AVC msg=audit(1314366345.339:40141): avc:  denied  { relabelfrom } for  pid=473 comm="cp" name="cluster.rng" dev=dm-0 ino=1831513 scontext=unconfined_u:system_r:corosync_t:s0 tcontext=unconfined_u:object_r:cluster_var_lib_t:s0 tclass=file
type=AVC msg=audit(1314366345.339:40141): avc:  denied  { relabelto } for  pid=473 comm="cp" name="cluster.rng" dev=dm-0 ino=1831513 scontext=unconfined_u:system_r:corosync_t:s0 tcontext=unconfined_u:object_r:cluster_var_lib_t:s0 tclass=file
type=SYSCALL msg=audit(1314366345.339:40141): arch=c000003e syscall=190 success=yes exit=0 a0=4 a1=7fffbbbaf650 a2=2038460 a3=2b items=1 ppid=441 pid=473 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="cp" exe="/bin/cp" subj=unconfined_u:system_r:corosync_t:s0 key=(null)
type=PATH msg=audit(1314366345.339:40141): item=0 name=(null) inode=1831513 dev=fd:00 mode=0100600 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:cluster_var_lib_t:s0

Comment 5 Nate Straz 2011-08-26 13:52:23 UTC
(In reply to comment #3)
> I am no selinux expert but by the look of it, I think they are coming from
> ccs_update_schema that's new in 6.2.
> 
> Interesting enough we see AVC only from the fence side of the scan and not the
> resource-agents bits (ccs_update_schema scans for both at runtime).

I have a feeling that I relabeled that binary while working on stuff.  comment #4 should be more accurate.

> What is the general process to get this fixed with selinux-devel guys?

Just explain how ccs_update_schema is run, from which context, and what files it needs to work with.  Then reassign the bug to selinux-policy.

Comment 6 Fabio Massimo Di Nitto 2011-09-06 12:14:36 UTC

*** This bug has been marked as a duplicate of bug 733337 ***