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 1312009 - [SELinux]: seeing avc denied for comm=mailx in rhel7.1
Summary: [SELinux]: seeing avc denied for comm=mailx in rhel7.1
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd
Version: 7.3
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: systemd-maint
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On: 1247522 1309317
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-02-25 13:59 UTC by Miroslav Grepl
Modified: 2016-03-08 16:05 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 1309317
Environment:
Last Closed: 2016-03-08 16:05:38 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Miroslav Grepl 2016-02-25 13:59:38 UTC
+++ This bug was initially created as a clone of Bug #1309317 +++

+++ This bug was initially created as a clone of Bug #1247522 +++

Description of problem:
selinux: seeing avc denied for comm=mailx in rhel7.1

Version-Release number of selected component (if applicable):
glusterfs-3.7.1-11.el7rhgs.x86_64
selinux-policy-3.13.1-35.el7

How reproducible:
Twice

Steps to Reproduce:
1. On a freshly installed rhs3.1 iso for rhel7.1, applied the new selinux policy - selinux-policy-3.13.1-35.el7
2. gluster nfs-ganesha enable/disable, we get the following avc denied message.

[root@nfs3 ~]# ausearch -m avc -ts recent
----
time->Tue Jul 28 03:20:31 2015
type=SYSCALL msg=audit(1438033831.489:1616): arch=c000003e syscall=2 success=no exit=-13 a0=7560f0 a1=441 a2=1b6 a3=7fff25d0e820 items=0 ppid=13790 pid=13791 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mailx" exe="/usr/bin/mailx" subj=system_u:system_r:sendmail_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1438033831.489:1616): avc:  denied  { write } for  pid=13791 comm="mailx" name="Python-2015-07-28-02:34:54-15814" dev="dm-1" ino=2264 scontext=system_u:system_r:sendmail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:abrt_var_cache_t:s0 tclass=dir
----
time->Tue Jul 28 03:21:14 2015
type=SYSCALL msg=audit(1438033874.444:1633): arch=c000003e syscall=2 success=no exit=-13 a0=18c00f0 a1=441 a2=1b6 a3=7fff48ba0840 items=0 ppid=14738 pid=14739 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mailx" exe="/usr/bin/mailx" subj=system_u:system_r:sendmail_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1438033874.444:1633): avc:  denied  { write } for  pid=14739 comm="mailx" name="Python-2015-07-28-02:34:54-15814" dev="dm-1" ino=2264 scontext=system_u:system_r:sendmail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:abrt_var_cache_t:s0 tclass=dir


But seems like this AVC is not harming any functionality as of now.

Actual results: seeing AVC denied message


Expected results: No avc denied messages


Additional info:

--- Additional comment from Red Hat Bugzilla Rules Engine on 2015-07-28 04:45:36 EDT ---

This bug is automatically being proposed for Red Hat Gluster Storage 3.1.0 by setting the release flag 'rhgs‑3.1.0' to '?'. 

If this bug should be proposed for a different release, please manually change the proposed release flag.

--- Additional comment from Soumya Koduri on 2015-07-28 10:08:44 EDT ---

I guess we know the cause of the issue -

During nfs-ganesha setup/teardown,

AVC reported --
type=SYSCALL msg=audit(07/28/2015 08:35:30.716:5169) : arch=x86_64 syscall=open success=no exit=-13(Permission denied) a0=0x20e10f0 a1=O_WRONLY|O_CREAT|O_APPEND a2=0666 a3=0x7ffd11cae1e0 items=0 ppid=6737 pid=6738 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=mailx exe=/usr/bin/mailx subj=system_u:system_r:sendmail_t:s0-s0:c0.c1023 key=(null) 
type=AVC msg=audit(07/28/2015 08:35:30.716:5169) : avc:  denied  { write } for  pid=6738 comm=mailx name=Python-2015-07-28-02:34:54-15814 dev="dm-1" ino=2264 scontext=system_u:system_r:sendmail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:abrt_var_cache_t:s0 tclass=dir 

in '/var/log/messages',
Jul 28 08:35:30 dhcp37-44 systemd: SELinux policy denies access.
Jul 28 08:35:30 dhcp37-44 python: detected unhandled Python exception in '/usr/sbin/pcs'
Jul 28 08:35:30 dhcp37-44 abrt-server: Duplicate: core backtrace
Jul 28 08:35:30 dhcp37-44 abrt-server: DUP_OF_DIR: /var/spool/abrt/Python-2015-07-28-02:34:54-15814
Jul 28 08:35:30 dhcp37-44 abrt-server: Deleting problem directory Python-2015-07-28-08:35:30-6708 (dup of Python-2015-07-28-02:34:54-15814)
Jul 28 08:35:30 dhcp37-44 abrt-server: Email address of sender was not specified. Would you like to do so now? If not, 'user@localhost' is to be used [y/N]
Jul 28 08:35:30 dhcp37-44 abrt-server: Email address of receiver was not specified. Would you like to do so now? If not, 'root@localhost' is to be used [y/N]
Jul 28 08:35:30 dhcp37-44 abrt-server: Sending an email...
Jul 28 08:35:30 dhcp37-44 abrt-server: /usr/sbin/sendmail: No such file or directory
Jul 28 08:35:30 dhcp37-44 abrt-server: . . . message not sent.
Jul 28 08:35:30 dhcp37-44 abrt-server: Error running '/bin/mailx'




[root@nfs3 ganesha]# cat /var/spool/abrt/Python-2015-07-28-02:34:54-15814/backtrace
utils.py:2135:serviceStatus:IndexError: list index out of range

Traceback (most recent call last):
  File "/usr/sbin/pcs", line 153, in <module>
    main(sys.argv[1:])
  File "/usr/sbin/pcs", line 145, in main
    status.status_cmd(argv)
  File "/usr/lib/python2.7/site-packages/pcs/status.py", line 13, in status_cmd
    full_status()
  File "/usr/lib/python2.7/site-packages/pcs/status.py", line 63, in full_status
    utils.serviceStatus("  ")
  File "/usr/lib/python2.7/site-packages/pcs/utils.py", line 2135, in serviceStatus
    print prefix + daemons[i] + ": " + status[i] + "/" + enabled[i]
IndexError: list index out of range

Local variables in innermost frame:
status: ['active', 'active', 'active', '']
i: 2
enabled: ['Failed to issue method call: Access denied', '']
ret: 1
prefix: '  '
daemons: ['corosync', 'pacemaker', 'pcsd']
out: 'Failed to issue


In '/usr/lib/python2.7/site-packages/pcs/utils.py',

def serviceStatus(prefix):
    if is_systemctl():
        print "Daemon Status:"
        daemons = ["corosync", "pacemaker", "pcsd"]
        out, ret = run(["systemctl", "is-active"] + daemons)
        status = out.split("\n")
        out, ret = run(["systemctl", "is-enabled"]+ daemons)
        enabled = out.split("\n")
        for i in range(len(daemons)):
            print prefix + daemons[i] + ": " + status[i] + "/" + enabled[i]

'ganesha-ha.script' runs 'pcs status' during setup/teardown of cluster, which in turn is using a python module to check the status of 'corosync', 'pacemaker' and 'pcsd' services. And looks like selinux policy on 'glusterd' service which invokes this script is blocking one of those systemd commands. And since variables 'enabled' is not populated, accessing that variable resulted in a exception. While trying to send a mail about this crash, 'abrt-server' received a SELinux denial to access 'mailx' service. 

That means there are two denials by selinux seen here. Can someone explain why "Jul 28 08:35:30 dhcp37-44 systemd: SELinux policy denies access." hasn't reported any AVCs, whereas invoking 'mailx' has?

--- Additional comment from Soumya Koduri on 2015-07-28 10:09:55 EDT ---

Also note that there are no functionality issues seen with these denials yet though reporting crash in messages may seem not right.

--- Additional comment from Milos Malik on 2015-07-29 02:31:24 EDT ---

Following message usually means that an USER_AVC appeared:
systemd: SELinux policy denies access

Could you attach AVCs and USER_AVCs too?
# ausearch -m avc -m user_avc -i -ts today

--- Additional comment from Meghana on 2015-07-29 02:55:36 EDT ---

type=USER_AVC msg=audit(07/29/2015 01:38:34.355:13684) : pid=1 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg='avc:  denied  { status } for auid=unset uid=root gid=root path=system scontext=system_u:system_r:glusterd_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=system  exe=/usr/lib/systemd/systemd sauid=root hostname=? addr=? terminal=?' 
----
type=SYSCALL msg=audit(07/29/2015 01:38:34.733:13685) : arch=x86_64 syscall=open success=no exit=-13(Permission denied) a0=0x25f80f0 a1=O_WRONLY|O_CREAT|O_APPEND a2=0666 a3=0x7ffcaff02460 items=0 ppid=11798 pid=11799 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=mailx exe=/usr/bin/mailx subj=system_u:system_r:sendmail_t:s0-s0:c0.c1023 key=(null) 
type=AVC msg=audit(07/29/2015 01:38:34.733:13685) : avc:  denied  { write } for  pid=11799 comm=mailx name=Python-2015-07-28-02:34:54-15814 dev="dm-1" ino=2264 scontext=system_u:system_r:sendmail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:abrt_var_cache_t:s0 tclass=dir

--- Additional comment from Apeksha on 2016-02-17 04:55:55 EST ---

i hit the same crash on my stup while setting up nfs-ganesha cluster. Note that i have done multiple times setup/teardown of nfs-ganesha cluster on this setup

[root@dhcp46-59 ~]# cat /var/spool/abrt/Python-2016-02-08-15\:33\:55-28283/backtrace 
utils.py:1962:serviceStatus:IndexError: list index out of range

Traceback (most recent call last):
  File "/usr/sbin/pcs", line 219, in <module>
    main(sys.argv[1:])
  File "/usr/sbin/pcs", line 159, in main
    cmd_map[command](argv)
  File "/usr/lib/python2.7/site-packages/pcs/status.py", line 16, in status_cmd
    full_status()
  File "/usr/lib/python2.7/site-packages/pcs/status.py", line 64, in full_status
    utils.serviceStatus("  ")
  File "/usr/lib/python2.7/site-packages/pcs/utils.py", line 1962, in serviceStatus
    print prefix + daemons[i] + ": " + status[i] + "/" + enabled[i]
IndexError: list index out of range

Local variables in innermost frame:
status: ['active', 'active', 'active', '']
i: 2
enabled: ['Failed to get unit file state for corosync.service: Access denied', '']
ret: 1
prefix: '  '
daemons: ['corosync', 'pacemaker', 'pcsd']
out: 'Failed to get unit file state for corosync.service: Access denied\n'




After disabling selinux , setup worked.


avc error:
type=AVC msg=audit(1455729058.666:101139): avc:  denied  { write } for  pid=27026 comm="mailx" name="Python-2016-02-08-15:33:55-28283" dev="dm-0" ino=35040612 scontext=system_u:system_r:sendmail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:abrt_var_cache_t:s0 tclass=dir

--- Additional comment from Apeksha on 2016-02-17 05:29:28 EST ---

we have a bug were corosync file goes missing - https://bugzilla.redhat.com/show_bug.cgi?id=1273288

so after getting this file from other server, and then trying to setup ganesha cluster, failed. since this file dint have proper labels and hence avc denied error msg.

After doing restorecon on that /etc/corosyc/corosyc.conf the setup worked.


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