Red Hat Bugzilla – Bug 1309317
[SELinux]: seeing avc denied for comm=mailx in rhel7.1
Last modified: 2016-11-03 23:08:52 EDT
+++ 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.
Jakub, I thought it should append inherited files in /var/cache/abrt?
Every time ABRT detects a new problem or a duplicate problem (problem means a coredump or an uncaught Python exception etc.) a new directory in /var/spool/abrt (formerly /var/tmp/abrt) is created (resp. updates the original problem directory in case of duplicate problems). After the directory is created (or the duplicate problem directory is localized) /usr/sbin/abrtd runs several shell scripts in the problem directory and one of those scripts executes /usr/bin/reporter-mailx which internally uses /usr/bin/mailx. The reporter-mailx binary should send a short email to root as a notification of the detected problem. If no MTA (sendmail, postfix, etc.) is installed on the machine, the mailx binary fails and tries to create the dead.letter file in its working directory which is the problem directory in our case.
We can configure libreport to not create the dead.letter file: diff --git a/src/plugins/reporter-mailx.c b/src/plugins/reporter-mailx.c index 47943ed..b45ede2 100644 --- a/src/plugins/reporter-mailx.c +++ b/src/plugins/reporter-mailx.c @@ -132,6 +132,12 @@ static void create_and_send_email( */ putenv((char*)"sendwait=1"); + /* Prevent mailx to create dead.letter if sending fails. The file is + * useless in our case and when the reporter is called from abrtd, SELinux + * complains a lot about mailx touching ABRT data. + */ + putenv((char*)"DEAD=/dev/null"); + if (notify_only) log(_("Sending a notification email to: %s"), email_to); else
Upstream pull request: https://github.com/abrt/libreport/pull/416
Created attachment 1148520 [details] Patch 1/1: mailx: stop creating dead.letter on mailx failures
Related testcase: https://github.com/abrt/abrt/tree/rhel7/tests/runtests/mailx-dead-letter
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-2307.html