Bug 2165752

Summary: SELinux policy prevents sendmail_t from performing Cyrus IMAP mail delivery
Product: Red Hat Enterprise Linux 8 Reporter: James Ralston <ralston>
Component: selinux-policyAssignee: Zdenek Pytela <zpytela>
Status: CLOSED ERRATA QA Contact: Milos Malik <mmalik>
Severity: unspecified Docs Contact:
Priority: low    
Version: 8.7CC: lvrabec, mmalik
Target Milestone: rcKeywords: Triaged
Target Release: 8.9Flags: pm-rhel: mirror+
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: selinux-policy-3.14.3-122.el8 Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-11-14 15:47:42 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description James Ralston 2023-01-30 22:23:20 UTC
Description of problem:

On RHEL8, SELinux is blocking sendmail from handing off mail to the local cyrusv2 mailer for delivery:

```
$ ausearch -i -m avc -ts today | tail -100
…
type=PROCTITLE msg=audit(2023-01-26 14:59:25.110:23439) : proctitle=sendmail: ./30QGlLWc393699 localhost: user open 
type=PATH msg=audit(2023-01-26 14:59:25.110:23439) : item=0 name=/run/cyrus/socket/lmtp inode=66752 dev=00:18 mode=socket,777 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:cyrus_var_run_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=CWD msg=audit(2023-01-26 14:59:25.110:23439) : cwd=/var/spool/mqueue 
type=SYSCALL msg=audit(2023-01-26 14:59:25.110:23439) : arch=x86_64 syscall=lstat success=no exit=EACCES(Permission denied) a0=0x7ffdccb6e970 a1=0x7ffdccb6e8e0 a2=0x7ffdccb6e8e0 a3=0x9 items=1 ppid=2455 pid=415005 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=smmsp sgid=smmsp fsgid=smmsp tty=(none) ses=unset comm=sendmail exe=/usr/sbin/sendmail.sendmail subj=system_u:system_r:sendmail_t:s0 key=(null) 
type=AVC msg=audit(2023-01-26 14:59:25.110:23439) : avc:  denied  { getattr } for  pid=415005 comm=sendmail path=/run/cyrus/socket/lmtp dev="tmpfs" ino=66752 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:cyrus_var_run_t:s0 tclass=sock_file permissive=0 
```

```
$ ausearch -i -m avc -ts today | audit2allow 
…
#============= sendmail_t ==============
allow sendmail_t cyrus_var_run_t:sock_file getattr;
```

Running `restorecon -FR -v /` (in essence, relabeling the entire OS) does not detect any mislabeling that would explain the above.

If I put `sendmail_t` into permissive mode and wait for sendmail to perform the next queue run, it successfully delivers all queued messages, resulting in these SELinux denials (which are overridden by permissive mode):

```
#============= sendmail_t ==============
allow sendmail_t cyrus_var_run_t:sock_file { getattr write };
```

We don’t see these SELinux denials on a RHEL7 host running Cyrus IMAP.

Inspecting the differences between RHEL7 and RHEL8, we see that in RHEL8, the Cyrus IMAP socket moved from `/var/lib/imap/socket/lmtp` to `/run/cyrus/socket/lmtp`:

```
--- cyrus-v2-mailer-rhel7.cf    2023-01-26 15:15:44.134902691 -0500
+++ cyrus-v2-mailer-rhel8.cf    2023-01-26 15:15:51.591047710 -0500
@@ -2,9 +2,9 @@
 ###   Cyrus V2 Mailer specification   ###
 #########################################
 
-#####  $Id: cyrusv2.m4,v 1.1 2002/06/01 21:14:57 ca Exp $  #####
+#####  $Id: cyrusv2.m4,v 1.2 2013-11-22 20:51:14 ca Exp $  #####
 
 Mcyrusv2,       P=[IPC], F=lsDFMnqXzA@/:|m,
                 S=EnvFromSMTP/HdrFromL, R=EnvToL/HdrToL, E=\r\n,
                 T=DNS/RFC822/SMTP,
-                A=FILE /var/lib/imap/socket/lmtp
+                A=FILE /run/cyrus/socket/lmtp
```

This move changed the SELinux file context of the socket file:

```
0 srwxrwxrwx. 1 root root system_u:object_r:cyrus_var_lib_t:s0 /var/lib/imap/socket/lmtp=
0 srwxrwxrwx. 1 root root system_u:object_r:cyrus_var_run_t:s0 /run/cyrus/socket/lmtp=
```

So, I strongly suspect the issue here is that the socket location was moved in RHEL8, which changed the SELinux file context of the socket from `cyrus_var_lib_t` to `cyrus_var_run_t`, but the SELinux policy for RHEL8 was not updated to permit `sendmail_t` access to `cyrus_var_run_t` in addition to `cyrus_var_lib_t`.

So one of two things needs to happen:

1. Create a new file context (e.g., `cyrus_lmtp_socket_t`) for the `/run/cyrus/socket/lmtp` file, add the necessary type transition, and permit `sendmail_t` `{getattr write}` on `cyrus_lmtp_socket_t:sock_file`.
2. Permit `sendmail_t` `{getattr write}` on `cyrus_var_run_t:sock_file`.
3. Change the filesystem contexts such that `/run/cyrus/socket/lmtp` has the `cyrus_var_lib_t` context (including the necessary type transition) instead of the `cyrus_var_run_t`.

To me, #1 seems like the best course of action, as #2 would permit sendmail_t access to sockets in `/run/cyrus/socket` that aren't related to LMTP mail delivery and thus it does not need. And #3 feels like a kluge. But any of these actions will accomplish the goal of not blocking mail delivery.

(I suspect this same issue will need to be fixed for RHEL9 as well, but we don't yet have any RHEL9 servers running Cyrus IMAP, so I cannot test.)

Package versions:

redhat-release-8.7-0.3.el8.x86_64
selinux-policy-targeted-3.14.3-108.el8_7.1.noarch
sendmail-8.15.2-34.el8.x86_64

Comment 5 Zdenek Pytela 2023-06-13 17:31:14 UTC
Thank you James for your analysis. I decided to update the cyrus_stream_connect() interface to using the new path.
If you think more detailed confinement like the cyrus_lmtp_socket_t type you suggested is worth the effort, it could be done in Fedora or RHEL 9, but we cannot make such changes in the current RHEL 8 development state.

Comment 6 Zdenek Pytela 2023-06-14 08:00:01 UTC
Commit to backport:
e2981c092 Update cyrus_stream_connect() to use sockets in /run

Comment 12 James Ralston 2023-06-16 19:36:34 UTC
Thanks Zdenek; I think updating cyrus_stream_connect() to use sockets in /run is perfectly reasonable.

Comment 16 errata-xmlrpc 2023-11-14 15:47:42 UTC
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 (selinux-policy bug fix and enhancement update), 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://access.redhat.com/errata/RHBA-2023:7091