Description of problem: Sendmail should be allowing access to this ClamAV milter socket. SELinux is preventing sendmail from 'connectto' accesses on the unix_stream_socket /run/clamav-milter/clamav-milter.socket. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that sendmail should be allowed connectto access on the clamav-milter.socket unix_stream_socket by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep sendmail /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:sendmail_t:s0 Target Context system_u:system_r:init_t:s0 Target Objects /run/clamav-milter/clamav-milter.socket [ unix_stream_socket ] Source sendmail Source Path sendmail Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-157.fc23.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 4.2.7-300.fc23.x86_64 #1 SMP Wed Dec 9 22:28:30 UTC 2015 x86_64 x86_64 Alert Count 32 First Seen 2015-12-20 12:52:35 EST Last Seen 2015-12-21 17:17:16 EST Local ID 2f67ce08-ecf2-457a-a712-e9653cc9dc3d Raw Audit Messages type=AVC msg=audit(1450736236.815:544): avc: denied { connectto } for pid=9232 comm="sendmail" path="/run/clamav-milter/clamav-milter.socket" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket permissive=1 Hash: sendmail,sendmail_t,init_t,unix_stream_socket,connectto Version-Release number of selected component: selinux-policy-3.13.1-157.fc23.noarch Additional info: reporter: libreport-2.6.3 hashmarkername: setroubleshoot kernel: 4.2.7-300.fc23.x86_64 type: libreport
clamav-milter is not transitioning to antivirus_t
Hi, Could you attach output of: # ps -efZ | grep init_t Thank you.
Here you go: system_u:system_r:init_t:s0 root 1 0 0 Jan03 ? 00:00:14 /usr/lib/systemd/systemd --switched-root --system --deserialize 21 system_u:system_r:init_t:s0 clamilt 1412 1 0 Jan03 ? 00:00:00 /usr/sbin/clamav-milter -c /etc/mail/clamav-milter.conf --nofork=yes system_u:system_r:init_t:s0 john 1901 1 0 Jan03 ? 00:00:00 /usr/lib/systemd/systemd --user system_u:system_r:init_t:s0 john 1905 1901 0 Jan03 ? 00:00:00 (sd-pam) system_u:system_r:init_t:s0 root 10062 1 0 Jan04 ? 00:00:00 /usr/lib/systemd/systemd-machined unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 john 30972 12818 0 17:58 pts/0 00:00:00 grep --color=auto init_t
As mentioned in bug #1292227, I think something with the new clamav-milter.service items is triggering this: +User=clamilt +Group=clamilt + +PrivateTmp=yes +PrivateDevices=yes +NoNewPrivileges=yes +CapabilityBoundingSet=CAP_KILL + +ReadOnlyDirectories=/etc +ReadOnlyDirectories=/usr +ReadOnlyDirectories=/var/lib
What does ls -Z /usr/sbin/clamav-milter show you?
Here you go: system_u:object_r:antivirus_exec_t:s0 /usr/sbin/clamav-milter
It appears that removing: NoNewPrivileges=yes allows it to transition to antivirus_t.
Let's see what the systemd folks have to say about this.
In order to make this work, you need to make typebounds init_t antivirus_t; allow init_t antivirus_exec_t:file entrypoint;
So, I tried: module av 1.0; require { type init_t; type antivirus_t; type antivirus_exec_t; class file { entrypoint }; } typebounds init_t antivirus_t; allow init_t antivirus_exec_t:file entrypoint; But clamav-milter still doesn't transition to antivirus_t with NoNewPrivileges=yes. I guess at this point I'll just pull NoNewPrivileges=yes from the service file, but I would really like some more information from systemd and/or selinux people as to whether or not that it is expected that this statement should interfere with SELinux transitions.
I've also tried: SELinuxContext=system_u:system_r:antivirus_t:s0 in the clamav-milter.service, but it fails to start with that for no reason that I can discern other than: systemd[4464]: Failed at step EXEC spawning /usr/sbin/clamav-milter: Operation not permitted even in permissive mode.
To be clear - this last tests were done on EL7.
I failed to see any discussion from comment 10 on this so I reported https://github.com/systemd/systemd/issues/3845. It appears other packagers are having same troubles https://jira.mariadb.org/browse/MDEV-10404
https://github.com/systemd/systemd/issues/3852 Systemd bug report on Selinuxcontext and NoNewPrivileges=yes incompatibility. Great work Orion.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.