Re: [exim-dev] MUAs that run sendmail/exim to send emails - …

Dr Andrew C Aitchison wrote:
> On Mon, 13 Dec 2010, David Woodhouse wrote:
>
>> On Mon, 2010-12-13 at 10:41 +0000, Graeme Fowler wrote:
>>> Now... again, poor little dumb brain time again: Why do we need Exim to
>>> be setuid root? Presumably this is so it can change user when invoked to
>>> do local deliveries as the right user (amongst myriad other things).
>>
>> Yeah. There are plenty of other MTAs with a split process setup where
>> only the *delivery* agent actually has root privileges. The *transport*
>> program doesn't need them.
>
> If I remove the suid bit from the exim binary on one of my client
> machines then run "mail" or pine as an ordinary user I get
> Failed to create spool file /var/spool/exim/input//1PS9Ig-0002Kz-Gi-D:
> Permission denied
> errors.
>
> (#ls -l /var/spool/exim/input/
> total 16
> drwxr-x--- 2 exim exim 4096 Dec 13 14:04 ./
> drwxr-xr-x 5 exim exim 4096 Jul 30 13:50 ../
>
> Do I have the wrong permissions on the spool directories ?)

Strictly from *my* viewpoint, yes. And - depending on how things shape up,
perhaps not just me..

I would have ownership exim_user:exim_group (actually eximd:postal here).

Pine, or the 'mail' caller would then need to be members of group 'postal'

In our case, those include exim, Dovecot, ClamAV, Prayer, Ecartis, and until we
shed the last one still in use, SpamAssassin.

Departing the 'legacy' Unix envelope just one more step - the only shell
accounts we permit on a *server* are those for the primary sysadmin, and no more
than 2 backup individuals in 'wheel'. Full stop.
(daemons being separate issues).

Anyone else uses a 'servICE' not serVER'. They do not NEED shell.
'Obsolete behaviour pattern' to hand out shell accounts.

>
> Anyway, that suggests to me that whilst it might in principle
> be possible to avoid root privilege for transport,
> as exim is currently implemented we can't avoid giving some
> write permissions to the *exim* spool directory (the mail queue)
> as well as any write permissions needed for deliveries.
>

Yes BUT. It is not hard to use 'group' privs to obviate the need for ANY of
these to be, or have elevation routes to 'root. Root privs aren't needed to
write. Only to bind to privileged port(s) [1] and to set euid to 'on box'
account-holder ID's. Which is either not needed if group privs are utilized,
ELSE a non-issue (virtual users who have no UID).

Yes, it is a mindset change - and a bit of work. Non-trivial work.

But it has positive security benefits well beyond whether Exim is exploitable/not.

The right sort of barriers also protect the rest of the system from exploits in
the OTHER 'postal workers'. And mail irrelevant things.

Bill

[1] The 'postal workers' do not need root even to bind to their ports if xinetd
or systrace hand the ports in question to Exim, Dovecot, et al. OR if an IP
toolset remaps/forwards to/from a non-privilged port. Spearate critter doing the
do either way.

The challenge is finding a way that improves security without adding yet-another
point for exploit of it *own* toolset...

And, of course, Exim should be made as secure as can be ...regardless...