Bug 1574303

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

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

(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.

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.

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).

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.

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?

(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.

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.

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.

Of course another disadvantage is that not all filesystems support POSIX ACLs.

selinux-policy-3.14.1-30.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-20854ee84e

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

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.

*** Bug 1584312 has been marked as a duplicate of this bug. ***

Great thanks... I'm out of testing time for a week or so but will give it a whirl when I can.