[exim-dev] [Bug 2276] Exim triggers DAC_OVERRIDE when runnin…

トップ ページ
このメッセージを削除
このメッセージに返信
著者: admin
日付:  
To: exim-dev
題目: [exim-dev] [Bug 2276] Exim triggers DAC_OVERRIDE when running on SELinux enabled system
https://bugs.exim.org/show_bug.cgi?id=2276

--- Comment #3 from Jaroslav Å karvada <jskarvad@???> ---
(In reply to Phil Pennock from comment #2)
Thanks for response.

> There are two distinct areas here: logs and spool.
>
> Logs: wontfix, we write as root, if there's any kind of exploitability, that
> should be filed as a bug.
>
> Suggestion: set `LOG_MODE=0660` in Exim's `Local/Makefile` when building,
> and use an ACL on the logs directory to automatically inherit group root
> writability when creating files.
>

This will probably not help with the DAC_OVERRIDE. I think the problem is that
root is writing to file owned by exim:exim, i.e. overriding the filesystem
ACLs. Of course it works, but is not logically correct. I think possible
solutions are:

- have the logs owned by exim:root
- have logger process running as exim user and logging everything through it.

I understand that dealing with this it's not worth the effort, that's why I
suggested adding DAC_OVERRIDE SELinux rule in the downstream bugzilla.

> Spool files: I don't think Exim should be touching spool files while still
> root. That should be happening as the Exim run-time user. I haven't looked
> at the relevant code recently, but if there's home directory delivering as
> the user in question, then perhaps that's the path leading to this
> happening, but this is speculation.
>
> Is there any way that we could get debug traces from Exim, showing what it
> was trying to do when it got permission denied on the _spool_ files please?


Unfortunately, I do not have debug trace for the spool files problem. The only
thing that I have at the moment is failure from the exim log:
2018-05-15 22:56:25 1fIgzf-0000ji-HV Spool error for
/var/spool/exim//input//1fIgzf-0000ji-HV-D: Permission denied

Which seems to belong to spool_open_datafile from spool_in.c.

There is written in the comment:
...
As called by deliver_message() (at least) we are operating as root.
...

But I didn't have time to look more closely.

--
You are receiving this mail because:
You are on the CC list for the bug.