Bug 1574303 - Exim cannot operate because of SELinux dac_override denial
Summary: Exim cannot operate because of SELinux dac_override denial
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1584312 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-03 03:37 UTC by Jonathan Briggs
Modified: 2018-05-31 16:21 UTC (History)
13 users (show)

Fixed In Version: selinux-policy-3.14.1-30.fc28
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-30 14:10:33 UTC
Type: Bug


Attachments (Terms of Use)

Description Jonathan Briggs 2018-05-03 03:37:18 UTC
Description of problem:
When Exim wants to write into its log files in /var/log/exim/main.log, panic.log, etc, it is denied. Then it fails to do anything.

The message looks like:
 AVC avc:  denied  { dac_override } for  pid=11942 comm="exim" capability=1  scontext=system_u:system_r:exim_t:s0 tcontext=system_u:system_r:exim_t:s0 tclass=capability 

The file permissions are:
# ls -lZd /var
drwxr-xr-x. 1 root root system_u:object_r:var_t:s0 222 May  2 18:36 /var
# ls -lZd /var/log
drwxr-xr-x. 1 root root system_u:object_r:var_log_t:s0 1714 May  2 18:09 /var/log
# ls -lZd /var/log/exim
drwxr-x---. 1 exim exim system_u:object_r:exim_log_t:s0 486 Mar 14 02:20 /var/log/exim
# ls -lZd /var/log/exim/main.log
-rw-r-----. 1 exim exim unconfined_u:object_r:exim_log_t:s0 962744 May  2 21:22 /var/log/exim/main.log


Version-Release number of selected component (if applicable):
exim-4.90.1-4.fc28.x86_64
selinux-policy-3.14.1-24.fc28.noarch

How reproducible:
Every time exim tries to receive an email or run a queue.

Steps to Reproduce:
1. Upgrade Fedora 27 to Fedora 28
2. Test that the Exim running in F27 still works in F28
3.

Actual results:
Exim starts up, but when that master exim spawns a sub-exim to handling incoming email or to run a queue it fails to work.

Expected results:
Exim should receive email and process queues.

Additional info:
Exim works properly with setenforce 0 active. This is not a proper fix.

Comment 1 Jaroslav Škarvada 2018-05-03 18:23:52 UTC
Hmm, probably exim tries to log to the file when it is running with UID=0, the files has 640 permissions and exim:exim owner, that's why it probably triggers the dac_override. In such case it's probably valid denial. We could (with ascending ugliness):

a) fix exim not to log when running with UID=0 (I am not sure whether it's easily doable)
b) change the file permissions to 660 and exim:root owner
c) add dac_override SELinux permission

Comment 2 Jonathan Briggs 2018-05-04 03:33:46 UTC
It isn't just the log files. I thought I'd try it with Exim set to use syslog only.

That worked for logs, but now Exim can't write spool files either. Same issue I think:

May 03 21:31:54 catbox.zlynx.org audit[9902]: AVC avc:  denied  { dac_override } for  pid=9902 comm="exim" capability=1  scontext=system_u:system_r:exim_t:s0 tcontext=system_u:system_r:exim_t:s0 tclass=capability permissive=0
May 03 21:31:54 catbox.zlynx.org exim[9902]: 2018-05-03 21:31:54 1fERRo-0002Zc-1E Spool error for /var/spool/exim//input//1fERRo-0002Zc-1E-D: Permission denied

Comment 3 Jaroslav Škarvada 2018-05-04 08:33:19 UTC
(In reply to Jonathan Briggs from comment #2)
> It isn't just the log files. I thought I'd try it with Exim set to use
> syslog only.
> 
> That worked for logs, but now Exim can't write spool files either. Same
> issue I think:
> 
> May 03 21:31:54 catbox.zlynx.org audit[9902]: AVC avc:  denied  {
> dac_override } for  pid=9902 comm="exim" capability=1 
> scontext=system_u:system_r:exim_t:s0 tcontext=system_u:system_r:exim_t:s0
> tclass=capability permissive=0
> May 03 21:31:54 catbox.zlynx.org exim[9902]: 2018-05-03 21:31:54
> 1fERRo-0002Zc-1E Spool error for /var/spool/exim//input//1fERRo-0002Zc-1E-D:
> Permission denied

Thanks for info, it's probably the same permissions mismatch problem, but now on different files. I am going to check when exim use privileged and unprivileged accounts, because I think it shouldn't write to the files when running privileged or the file permissions/owner should be changed to be consistent.

Comment 4 Dominic Search 2018-05-14 05:17:10 UTC
Any progress on this?  I've just run into the same problem during a server rebuild.  Exim version 4.90_1 is running flawlessly on Fedora 27, but version 4.91 breaks as described by Jonathan on exactly the same setup under Fedora 28.

I've tried your fix b) which works so long as nothing (like the logrotate) deletes the logs, at which point exim recreates them as exim:exim 600 and promptly triggers an avc. I could modify the logrotate script to create an empty file with the right owner/permissions, but that's just sticky plaster on an unstable system.  Really if fix b) is the answer then it needs coding into exim itself.

Comment 5 Jaroslav Škarvada 2018-05-14 10:48:35 UTC
Unfortunately, it doesn't seem to be easily fixable. I created upstream bugzilla:
https://bugs.exim.org/show_bug.cgi?id=2276

IMHO there is no related change in exim-4.90 vs 4.91, the difference is probably in SELinux policy which is now probably more strict. So that's why I am requesting SELinux policy workaround/rule until fixed (if ever).

Comment 6 Jaroslav Škarvada 2018-05-14 11:22:09 UTC
Upstream rejected to fix it. Patching the code downstream to use exim:root with 0660 mode instead of exim:exim can have side effects (there is probably good need for the exim group). Rewriting the suid legacy code to have another process running just for logging seems a bit overhead for downstream maintenance.

Comment 7 Dominic Search 2018-05-14 14:38:00 UTC
Thanks for pursuing the issue.  I have to agree with the Exim people when they say this sounds like it is an selinux policy issue.  Where do we go from here?... can you submit a fix request to the Fedora selinux team?

Comment 8 Jaroslav Škarvada 2018-05-15 08:43:57 UTC
(In reply to Dominic Search from comment #7)
> Thanks for pursuing the issue.  I have to agree with the Exim people when
> they say this sounds like it is an selinux policy issue.  Where do we go
> from here?... can you submit a fix request to the Fedora selinux team?

Actually, I think it's bad design, which has been caught by the SELinux. Root shouldn't write to files where only exim user has permission to write. But in this case it's easier to add SELinux exception / rule than rewrite the legacy software. I reassigned the bug to SELinux component and it should be processed by SELinux maitainers.

Comment 9 Jaroslav Škarvada 2018-05-16 09:07:19 UTC
Another possible solution is to recompile exim with SPOOL_MODE and LOG_MODE set to 0660 instead of the default 0640 and adding root to the exim group. At the moment I am not aware of any other package in Fedora adding root to special groups - to be honest it seems crazy to me. So returning the DAC_OVERRIDE to be noaudit rule for exim is probably the best solution here.

Comment 10 Dominic Search 2018-05-19 00:02:19 UTC
Actually, setting SPOOL_MODE and LOG_MODE to 0660 might just work as it would then be possible to give root proper access via POSIX ACLs... as in:

rm -f /var/log/exim/*
setfacl -m user:root:rwx /var/log/exim
setfacl -m default:user:root:rw- /var/log/exim

The standard group file permission acts to mask the maximum effective permission that root will actually be granted this way via ACLs.  As things currently stand Exim will recreate its log file as mode 0640 which limits root's access to read only.  If Exim were to recreate as mode 0660 then root's write access would no longer be masked off and no DAC_OVERRIDE avc would be generated.

A possible disadvantage is that I don't think tar archives ACLs by default (you need to use the --acls option) and that is bound to catch some people out.

Comment 11 Dominic Search 2018-05-19 00:13:05 UTC
Of course another disadvantage is that not all filesystems support POSIX ACLs.

Comment 12 Fedora Update System 2018-05-27 19:21:36 UTC
selinux-policy-3.14.1-30.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-20854ee84e

Comment 13 Fedora Update System 2018-05-28 15:48:50 UTC
selinux-policy-3.14.1-30.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-20854ee84e

Comment 14 Fedora Update System 2018-05-30 14:10:33 UTC
selinux-policy-3.14.1-30.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

Comment 15 Joe Orton 2018-05-31 16:13:08 UTC
*** Bug 1584312 has been marked as a duplicate of this bug. ***

Comment 16 Dominic Search 2018-05-31 16:21:47 UTC
Great thanks... I'm out of testing time for a week or so but will give it a whirl when I can.


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