Fedora's selinux package has a contributed policy for Courier, include/contrib/courier.if, which has two issues (that I found so far) with my upstream rpm packages. My rpm packages have worked this way for a long time, probably 15+ years, or so, this is not a recent change. The only thing that changed is that I'm actually tried to run in enforcing mode late last year, and ran into this. I'm picking this issue up now, for one last college try to figure out the fix.
I couldn't figure out how courier.if works; so last time after doing some random reading, I was able to come up with a band-aid for the first issue. The rpm package installs a binary in /var/www/cgi-bin that talks to the running webmail daemon over an AF_Unix socket. selinux's policy was labeling the /var/www/cgi-bin binary, and blocking its socket connection. The band- aid was this additional local policy:
policy_module(courier_webmail, 1.0)
require { type httpd_sys_script_t; type courier_spool_t; };
allow httpd_sys_script_t courier_spool_t:dir search_dir_perms; allow httpd_sys_script_t courier_spool_t:sock_file manage_sock_file_perms;
That seemed innocent enough. But I revisited the entire package this week, and found two more issues.
The first one is an additional AVC that was now blocking the same webmail binary:
type=AVC msg=audit(1589086763.118:1319): avc: denied { connectto } for pid=674413 comm="webmail" path="/var/spool/courier/sqwebmail.sock" scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=0
This was new, I could not figure out why the target context was unconfined, because:
[root@jack ~]# ls -alZ /var/spool/courier/sqwebmail.sock srwxrwxrwx. 1 root root system_u:object_r:courier_spool_t:s0 0 May 10 01:15 /var/spool/courier/sqwebmail.sock
As a band-aid on top of the first band-aid, I added
allow httpd_sys_script_t unconfined_service_t:unix_stream_socket connectto;
to the local policy, to get it working. But this doesn't seem ideal.
The second issue was that an individual uninstall of one of the rpm- subpackages was hanging. selinux was blocking a signal sent by binary that %preun runs. The signal is sent to the running process:
type=AVC msg=audit(1589082060.526:1156): avc: denied { signal } for pid=672912 comm="courierlogger" scontext=unconfined_u:unconfined_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=process permissive=0
and
type=AVC msg=audit(1589082160.527:1172): avc: denied { sigkill } for pid=672912 comm="courierlogger" scontext=unconfined_u:unconfined_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=process permissive=0
The main rpm package's systemd unit runs a startup script that inventories which subpackages are installed, and starts each one's service. Manually uninstalling an rpm subpackage executes a %preun that stops just its own service, and this part is getting blocked. The binary that sends the signal appears to be labeled by the contributed Fedora policy:
rwxr-xr-x. 1 daemon daemon system_u:object_r:courier_exec_t:s0 25296 May 9 23:19 /usr/sbin/courierlogger
The binary is trying to send a signal to one of these processes:
system_u:system_r:unconfined_service_t:s0 root 780748 780747 0 01:15 ? 00:00:00 /usr/lib/courier/sbin/couriertcpd [parameters]
r-xr-xr-x. 1 daemon daemon system_u:object_r:bin_t:s0 142456 May 10 01:14 /usr/lib/courier/sbin/couriertcpd
I could avoid this by systemctl stop in %preun and systemctl start in %postun, I suppose. Startup and shutdown, which sends the same signal via the same binary, seems to work when the main rpm package runs systemctl stop. But doing it this way stops and restarts everything when a single subpackage gets removed, this is not ideal.
On 5/10/20 3:20 PM, Sam Varshavchik wrote:
Fedora's selinux package has a contributed policy for Courier, include/contrib/courier.if, which has two issues (that I found so far) with my upstream rpm packages. My rpm packages have worked this way for a long time, probably 15+ years, or so, this is not a recent change. The only thing that changed is that I'm actually tried to run in enforcing mode late last year, and ran into this. I'm picking this issue up now, for one last college try to figure out the fix.
I couldn't figure out how courier.if works; so last time after doing some random reading, I was able to come up with a band-aid for the first issue. The rpm package installs a binary in /var/www/cgi-bin that talks to the running webmail daemon over an AF_Unix socket. selinux's policy was labeling the /var/www/cgi-bin binary, and blocking its socket connection. The band-aid was this additional local policy:
policy_module(courier_webmail, 1.0)
require { type httpd_sys_script_t; type courier_spool_t; };
allow httpd_sys_script_t courier_spool_t:dir search_dir_perms; allow httpd_sys_script_t courier_spool_t:sock_file manage_sock_file_perms;
That seemed innocent enough. But I revisited the entire package this week, and found two more issues.
The first one is an additional AVC that was now blocking the same webmail binary:
type=AVC msg=audit(1589086763.118:1319): avc: denied { connectto } for pid=674413 comm="webmail" path="/var/spool/courier/sqwebmail.sock" scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=0
This was new, I could not figure out why the target context was unconfined, because:
[root@jack ~]# ls -alZ /var/spool/courier/sqwebmail.sock srwxrwxrwx. 1 root root system_u:object_r:courier_spool_t:s0 0 May 10 01:15 /var/spool/courier/sqwebmail.sock
As a band-aid on top of the first band-aid, I added
allow httpd_sys_script_t unconfined_service_t:unix_stream_socket connectto;
to the local policy, to get it working. But this doesn't seem ideal.
The second issue was that an individual uninstall of one of the rpm-subpackages was hanging. selinux was blocking a signal sent by binary that %preun runs. The signal is sent to the running process:
type=AVC msg=audit(1589082060.526:1156): avc: denied { signal } for pid=672912 comm="courierlogger" scontext=unconfined_u:unconfined_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=process permissive=0
and
type=AVC msg=audit(1589082160.527:1172): avc: denied { sigkill } for pid=672912 comm="courierlogger" scontext=unconfined_u:unconfined_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=process permissive=0
The main rpm package's systemd unit runs a startup script that inventories which subpackages are installed, and starts each one's service. Manually uninstalling an rpm subpackage executes a %preun that stops just its own service, and this part is getting blocked. The binary that sends the signal appears to be labeled by the contributed Fedora policy:
rwxr-xr-x. 1 daemon daemon system_u:object_r:courier_exec_t:s0 25296 May 9 23:19 /usr/sbin/courierlogger
The binary is trying to send a signal to one of these processes:
system_u:system_r:unconfined_service_t:s0 root 780748 780747 0 01:15 ? 00:00:00 /usr/lib/courier/sbin/couriertcpd [parameters]
r-xr-xr-x. 1 daemon daemon system_u:object_r:bin_t:s0 142456 May 10 01:14
I could avoid this by systemctl stop in %preun and systemctl start in%postun, I suppose. Startup and shutdown, which sends the same signal via the same binary, seems to work when the main rpm package runs systemctl stop. But doing it this way stops and restarts everything when a single subpackage gets removed, this is not ideal.
Hi,
Thank you for reporting this issue to us.
Can please run following commands before you reproduce the scenario again:
# chcon -t courier_exec_t /usr/lib/courier/sbin/couriertcpd # dnf install selinux-policy-devel -y $ cat httpd_courier.te policy_module(httpd_courier, 1.0) gen_require(` type httpd_sys_script_t; type courier_spool_t; type system_mail_t; ')
stream_connect_pattern(httpd_sys_script_t, courier_spool_t, courier_spool_t, system_mail_t)
# make -f /usr/share/selinux/devel/Makefile httpd_courier.pp # semodule -i httpd_courier.pp
### reproduce the scenario
And attach output of: # ausearch -m AVC -ts today
Thanks, Lukas.
selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.or...
Lukas Vrabec writes:
Can please run following commands before you reproduce the scenario again:
# chcon -t courier_exec_t /usr/lib/courier/sbin/couriertcpd # dnf install selinux-policy-devel -y $ cat httpd_courier.te policy_module(httpd_courier, 1.0) gen_require(` type httpd_sys_script_t; type courier_spool_t; type system_mail_t; ')
stream_connect_pattern(httpd_sys_script_t, courier_spool_t, courier_spool_t, system_mail_t)
# make -f /usr/share/selinux/devel/Makefile httpd_courier.pp # semodule -i httpd_courier.pp
### reproduce the scenario
And attach output of: # ausearch -m AVC -ts today
The above was done:
[root@jack ~]# semodule --list | grep courier courier httpd_courier [root@jack ~]# ls -alZ /usr/lib/courier/sbin/couriertcpd -r-xr-xr-x. 1 daemon daemon system_u:object_r:courier_exec_t:s0 142456 May 10 01:14 /usr/lib/courier/sbin/couriertcpd
The server daemons were restarted.
Both the webmail socket connection was blocked, as well as signals to courierlogger. The first two AVCs is the webmail connection:
---- time->Mon May 11 20:00:38 2020 type=AVC msg=audit(1589241638.443:3693): avc: denied { connectto } for pid=1629725 comm="webmail" path="/var/spool/courier/sqwebmail.sock" scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=0 ---- time->Mon May 11 20:00:54 2020 type=AVC msg=audit(1589241654.975:3701): avc: denied { connectto } for pid=1629864 comm="webmail" path="/var/spool/courier/sqwebmail.sock" scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=0
The socket and the cgi-bin binary are labeled thusly:
[root@jack ~]# ls -alZ /var/spool/courier/sqwebmail.sock srwxrwxrwx. 1 root root system_u:object_r:courier_spool_t:s0 0 May 11 20:01 /var/spool/courier/sqwebmail.sock [root@jack ~]# ls -alZ /var/www/cgi-bin/webmail -r-xr-xr-x. 1 root bin system_u:object_r:httpd_sys_script_exec_t:s0 31464 May 10 01:14 /var/www/cgi-bin/webmail
The remaining AVCs are for the signal issue:
---- time->Mon May 11 20:02:13 2020 type=AVC msg=audit(1589241733.799:3740): avc: denied { signal } for pid=1630215 comm="courierlogger" scontext=unconfined_u:unconfined_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=process permissive=0 ---- time->Mon May 11 20:02:23 2020 type=AVC msg=audit(1589241743.799:3743): avc: denied { sigkill } for pid=1630215 comm="courierlogger" scontext=unconfined_u:unconfined_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=process permissive=0 ---- time->Mon May 11 20:02:33 2020 type=AVC msg=audit(1589241753.800:3744): avc: denied { sigkill } for pid=1630215 comm="courierlogger" scontext=unconfined_u:unconfined_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=process permissive=0 ---- time->Mon May 11 20:02:43 2020 type=AVC msg=audit(1589241763.800:3751): avc: denied { sigkill } for pid=1630215 comm="courierlogger" scontext=unconfined_u:unconfined_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=process permissive=1 ---- time->Mon May 11 20:02:43 2020 type=AVC msg=audit(1589241763.807:3752): avc: denied { signal } for pid=1630256 comm="courierlogger" scontext=unconfined_u:unconfined_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=process permissive=1
Noting that the running processes are unconfined, even though the binary is labeled:
# ps -efZ | grep courierlogger system_u:system_r:unconfined_service_t:s0 root 1630457 1 0 20:10 ? 00:00:00 /usr/sbin/courierlogger - ... every one of them root@jack ~]# ls -alZ /usr/sbin/courierlogger -rwxr-xr-x. 1 daemon daemon system_u:object_r:courier_exec_t:s0 25296 May 9 23:19 /usr/sbin/courierlogger
On 5/12/20 2:18 AM, Sam Varshavchik wrote:
Lukas Vrabec writes:
Can please run following commands before you reproduce the scenario again:
# chcon -t courier_exec_t /usr/lib/courier/sbin/couriertcpd # dnf install selinux-policy-devel -y $ cat httpd_courier.te policy_module(httpd_courier, 1.0) gen_require(` type httpd_sys_script_t; type courier_spool_t; type system_mail_t; ')
stream_connect_pattern(httpd_sys_script_t, courier_spool_t, courier_spool_t, system_mail_t)
# make -f /usr/share/selinux/devel/Makefile httpd_courier.pp # semodule -i httpd_courier.pp
### reproduce the scenario
And attach output of: # ausearch -m AVC -ts today
The above was done:
[root@jack ~]# semodule --list | grep courier courier httpd_courier [root@jack ~]# ls -alZ /usr/lib/courier/sbin/couriertcpd -r-xr-xr-x. 1 daemon daemon system_u:object_r:courier_exec_t:s0 142456 May 10 01:14 /usr/lib/courier/sbin/couriertcpd
The server daemons were restarted.
Both the webmail socket connection was blocked, as well as signals to courierlogger. The first two AVCs is the webmail connection:
time->Mon May 11 20:00:38 2020 type=AVC msg=audit(1589241638.443:3693): avc: denied { connectto } for pid=1629725 comm="webmail" path="/var/spool/courier/sqwebmail.sock" scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=0
time->Mon May 11 20:00:54 2020 type=AVC msg=audit(1589241654.975:3701): avc: denied { connectto } for pid=1629864 comm="webmail" path="/var/spool/courier/sqwebmail.sock" scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=0
The socket and the cgi-bin binary are labeled thusly:
[root@jack ~]# ls -alZ /var/spool/courier/sqwebmail.sock srwxrwxrwx. 1 root root system_u:object_r:courier_spool_t:s0 0 May 11 20:01 /var/spool/courier/sqwebmail.sock [root@jack ~]# ls -alZ /var/www/cgi-bin/webmail -r-xr-xr-x. 1 root bin system_u:object_r:httpd_sys_script_exec_t:s0 31464 May 10 01:14 /var/www/cgi-bin/webmail
The remaining AVCs are for the signal issue:
time->Mon May 11 20:02:13 2020 type=AVC msg=audit(1589241733.799:3740): avc: denied { signal } for pid=1630215 comm="courierlogger" scontext=unconfined_u:unconfined_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=process permissive=0
time->Mon May 11 20:02:23 2020 type=AVC msg=audit(1589241743.799:3743): avc: denied { sigkill } for pid=1630215 comm="courierlogger" scontext=unconfined_u:unconfined_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=process permissive=0
time->Mon May 11 20:02:33 2020 type=AVC msg=audit(1589241753.800:3744): avc: denied { sigkill } for pid=1630215 comm="courierlogger" scontext=unconfined_u:unconfined_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=process permissive=0
time->Mon May 11 20:02:43 2020 type=AVC msg=audit(1589241763.800:3751): avc: denied { sigkill } for pid=1630215 comm="courierlogger" scontext=unconfined_u:unconfined_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=process permissive=1
time->Mon May 11 20:02:43 2020 type=AVC msg=audit(1589241763.807:3752): avc: denied { signal } for pid=1630256 comm="courierlogger" scontext=unconfined_u:unconfined_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=process permissive=1
Noting that the running processes are unconfined, even though the binary is labeled:
# ps -efZ | grep courierlogger system_u:system_r:unconfined_service_t:s0 root 1630457 1 0 20:10 ? 00:00:00 /usr/sbin/courierlogger - ... every one of them root@jack ~]# ls -alZ /usr/sbin/courierlogger -rwxr-xr-x. 1 daemon daemon system_u:object_r:courier_exec_t:s0 25296 May 9 23:19 /usr/sbin/courierlogger
For some reason courierlogger runs as unconfined_service_t.
Can you describe flow how binaries are executed? Also can you attach systemd unit file executing this service?
Thanks, Lukas.
selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.or...
Lukas Vrabec writes:
For some reason courierlogger runs as unconfined_service_t.
Can you describe flow how binaries are executed? Also can you attach systemd unit file executing this service?
The starting point is this unit file:
https://github.com/svarshavchik/courier/blob/master/courier/courier.service....
The @datadir@ placeholder is /usr/lib/courier/share
The courier.sysvinit script is this one:
https://github.com/svarshavchik/courier/blob/master/courier/courier.sysvinit...
The first of the two problems: the cgi-bin binary that gets blocked from connecting to the AF_UNIX socket that the webmail server is listening on. Line 76 in this courier.sysvinit script runs the webmaild script:
https://github.com/svarshavchik/courier/blob/master/courier/courier/webmaild...
Line 41 of this script executes @courierlogger@, which is going to be /usr/sbin/courierlogger
-rwxr-xr-x. 1 daemon daemon system_u:object_r:courier_exec_t:s0 25296 May 9 23:19 /usr/sbin/courierlogger
As directed by the command on line 41, courierlogger forks and execs /usr/lib/courier/libexec/courier/sqwebmaild, which is:
-r-xr-xr-x. 1 daemon daemon system_u:object_r:bin_t:s0 1002664 May 10 01:14 /usr/lib/courier/libexec/courier/sqwebmaild
After fork/execing this, courierlogger drops root and runs as daemon uid/gid from this point on.
Meanwhile, the sqwebmaild binary creates this socket:
srwxrwxrwx. 1 root root system_u:object_r:courier_spool_t:s0 0 May 11 20:10 /var/spool/courier/sqwebmail.sock
And apache executes this:
r-xr-xr-x. 1 root bin system_u:object_r:httpd_sys_script_exec_t:s0 31464 May 10 01:14 /var/www/cgi-bin/webmail
which gets an AVC connecting to /var/spool/courier/sqwebmail.sock
The other issue is the SIGTERM/SIGKILL to the courierlogger processes getting blocked.
Line 173 of the same courier.sysvinit script, that runs from this unit file, executes this imapd script:
https://github.com/svarshavchik/courier/blob/master/courier/courier/imapd.rc...
This one, on line 54, also runs courierlogger, and this instance forks and execs the imapd process (also dropping root after forking off the child process).
The imapd rpm's subpackage's %preun:
if test "$1" = "0" then /usr/lib/courier/sbin/imapd stop /usr/lib/courier/sbin/imapd-ssl stop fi
This ends up executing
@courierlogger@ -pid=$PIDFILE -stop
from line 63 of the same imapd(.rc) script, which executes the same courierlogger binary. This instance opens a pid file that has the pid of the daemon instance of courierlogger that's currently running, and attempts to SIGINT/SIGKILL it.
It opens and reads the pid file without issues, gets the pid, the sigint/sigkill gets blocked.
Hi Sam,
It looks like there is missing file context definition for files in /usr/lib/courier/libexec/
Can you please try to label whole directory as "courier_exec_t" ?
# semanage fcontext -a -t courier_exec_t /usr/lib/courier/libexec(/.*)? # restorecon -Rv /usr/lib/courier
Can you then reproduce your scenario?
Thanks, Lukas.
On 5/12/20 11:54 PM, Sam Varshavchik wrote:
Lukas Vrabec writes:
For some reason courierlogger runs as unconfined_service_t.
Can you describe flow how binaries are executed? Also can you attach systemd unit file executing this service?
The starting point is this unit file:
https://github.com/svarshavchik/courier/blob/master/courier/courier.service....
The @datadir@ placeholder is /usr/lib/courier/share
The courier.sysvinit script is this one:
https://github.com/svarshavchik/courier/blob/master/courier/courier.sysvinit...
The first of the two problems: the cgi-bin binary that gets blocked from connecting to the AF_UNIX socket that the webmail server is listening on. Line 76 in this courier.sysvinit script runs the webmaild script:
https://github.com/svarshavchik/courier/blob/master/courier/courier/webmaild...
Line 41 of this script executes @courierlogger@, which is going to be /usr/sbin/courierlogger
-rwxr-xr-x. 1 daemon daemon system_u:object_r:courier_exec_t:s0 25296 May 9 23:19 /usr/sbin/courierlogger
As directed by the command on line 41, courierlogger forks and execs /usr/lib/courier/libexec/courier/sqwebmaild, which is:
-r-xr-xr-x. 1 daemon daemon system_u:object_r:bin_t:s0 1002664 May 10 01:14 /usr/lib/courier/libexec/courier/sqwebmaild
After fork/execing this, courierlogger drops root and runs as daemon uid/gid from this point on.
Meanwhile, the sqwebmaild binary creates this socket:
srwxrwxrwx. 1 root root system_u:object_r:courier_spool_t:s0 0 May 11 20:10 /var/spool/courier/sqwebmail.sock
And apache executes this:
r-xr-xr-x. 1 root bin system_u:object_r:httpd_sys_script_exec_t:s0 31464 May 10 01:14 /var/www/cgi-bin/webmail
which gets an AVC connecting to /var/spool/courier/sqwebmail.sock
The other issue is the SIGTERM/SIGKILL to the courierlogger processes getting blocked.
Line 173 of the same courier.sysvinit script, that runs from this unit file, executes this imapd script:
https://github.com/svarshavchik/courier/blob/master/courier/courier/imapd.rc...
This one, on line 54, also runs courierlogger, and this instance forks and execs the imapd process (also dropping root after forking off the child process).
The imapd rpm's subpackage's %preun:
if test "$1" = "0" then /usr/lib/courier/sbin/imapd stop /usr/lib/courier/sbin/imapd-ssl stop fi
This ends up executing
@courierlogger@ -pid=$PIDFILE -stop
from line 63 of the same imapd(.rc) script, which executes the same courierlogger binary. This instance opens a pid file that has the pid of the daemon instance of courierlogger that's currently running, and attempts to SIGINT/SIGKILL it.
It opens and reads the pid file without issues, gets the pid, the sigint/sigkill gets blocked.
selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.or...
Lukas Vrabec writes:
Hi Sam,
It looks like there is missing file context definition for files in /usr/lib/courier/libexec/
Can you please try to label whole directory as "courier_exec_t" ?
# semanage fcontext -a -t courier_exec_t /usr/lib/courier/libexec(/.*)? # restorecon -Rv /usr/lib/courier
Can you then reproduce your scenario?
I tried this after also updating to F32. The resulting relabeling:
Relabeled /usr/lib/courier/libexec from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/courier from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/courier/sqwebpasswd from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/courier/courierd from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/courier/aliascreate from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/courier/sqwebmaild from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/courier/submit from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/courier/aliascombine from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/courier/submitmkdir from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/courier/imaplogin from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/courier/makedatprog from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/courier/modules from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/courier/modules/fax from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/courier/modules/fax/courierfax from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/courier/modules/esmtp from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/courier/modules/esmtp/courieresmtp from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/courier/modules/esmtp/addcr from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/courier/modules/esmtp/courieresmtpd from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/courier/modules/uucp from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/courier/modules/uucp/courieruucp from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/courier/modules/dsn from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/courier/modules/dsn/courierdsn from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/courier/modules/local from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/courier/modules/local/courierdeliver from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/courier/modules/local/courierlocal from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/courier/aliasexp from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/courier/courierfilter from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/courier/pcpd from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/filters from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/filters/perlfilter from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/filters/ratefilter from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/filters/verifyfilter from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0 Relabeled /usr/lib/courier/libexec/filters/dupfilter from system_u:object_r:bin_t:s0 to system_u:object_r:courier_exec_t:s0
After a server restart, the result was a slightly different AVC:
Additional Information: Source Context system_u:system_r:httpd_sys_script_t:s0 Target Context system_u:object_r:courier_spool_t:s0 Target Objects /var/spool/courier [ dir ] Source webmail Source Path webmail Port <Unknown> Host jack Source RPM Packages Target RPM Packages courier-1.0.13.20200509-101.fc32.x86_64 SELinux Policy RPM selinux-policy-targeted-3.14.5-38.fc32.noarch Local Policy RPM selinux-policy-targeted-3.14.5-38.fc32.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name jack Platform Linux jack 5.6.11-300.fc32.x86_64 #1 SMP Wed May 6 19:12:19 UTC 2020 x86_64 x86_64 Alert Count 8 First Seen 2020-05-16 21:43:39 EDT Last Seen 2020-05-16 22:07:47 EDT Local ID ac01b623-e181-48dc-a097-fea6c8dd27b3
Raw Audit Messages type=AVC msg=audit(1589681267.341:2551): avc: denied { search } for pid=322657 comm="webmail" name="courier" dev="md125" ino=5901229 scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=system_u:object_r:courier_spool_t:s0 tclass=dir permissive=0
It's still blocking the same connect() call:
322694 connect(3, {sa_family=AF_UNIX, sun_path="/var/spool/courier/sqwebmail.sock"}, 110) = -1 EACCES (Permission denied)
The original avc was connectto, it's now search. The directory seems to be labeled:
drwxr-xr-x. 12 bin bin system_u:object_r:courier_spool_t:s0 4096 May 16 22:07 /var/spool/courier
srwxrwxrwx. 1 root root system_u:object_r:courier_spool_t:s0 0 May 16 22:13 /var/spool/courier/sqwebmail.sock
The other issue – with the SIGINT/SIGKILL from rpm scriptlets getting blocked – still exists too; however I'll work on changing the scriptlets to use systemctl to restart everything. This is less ideal than just stopping the individual service, but it should work.
The good news is that the relabeling does not appear to have any ill effects. /usr/lib/courier/libexec holds all core executables, so I wanted to spot-check; I spot checked a few, they seemed to work, but I haven't checked all of them.
Just to remain in sync on this, I restore the default configuration:
semanage fcontext -d '/usr/lib/courier/libexec(/.*)?' restorecon -Rv /usr/lib/courier
Thanks,
selinux@lists.fedoraproject.org