Author: W B Hacker Date: To: Ted Cooper CC: exim-dev Subject: Re: [exim-dev] What user should ${run...} in config file run as?
Ted Cooper wrote: > On 13/12/10 10:34, David Woodhouse wrote:
>> Why the hell did this work anyway?
>>
>> cat> e.conf<<'EEE'
>> spool_directory = ${run{/bin/chown root:root /var/spool/exim4/setuid}} ${run{/bin/chmod 4755 /var/spool/exim4/setuid}}
>> EEE
>> exim -Ce.conf -q
>>
>> Why are we invoking ${run...} directives in the config file as root? Why
>> aren't we doing it as the Exim user?
>
> That's a pretty good point. I can't think of a good reason why it
> shouldn't be run as exim user - even if someone needs a program run as
> root, it's trivial to write a setuid wrapper for it or use something
> like ${readsocket}
Or *safer* to step back and as WHY a mail infrastructure should *need* any such
privs. At least w/o restriction to known and planned channels.
>
> Of course it forces all programs being run to have all of their files
> owned by exim too (unless wrapped) or some group which makes them more
> tightly coupled.
'group is the key.
IMNSHO, it makes eminent sense to gather all the 'mailish' needfuls and use one
or more bespoke group and appropriate cross-memberships, so as to not only
better control privs, but make their joint and several duties and doings more
visible and obvious when the overworked sysadmin returns to look at something
that has 'JFW' for so long the details are hard to remember.
'Self documenting' 'coz too often there ain't no other kind of docs 'locally'.
> It does reduce the chances of being able to run
> something as root inadvertently though.
>
Greatly so.
Furthermore - it moves any 'leakage' due to careless externals OFF the plate of
the devel team and back onto faux pas made - or not made - by the sysadmin.
Those never were, nor ever will be, under devel's control.
> Is Exim being made less flexible and more difficult to use?
Not less flexible. no.
Difficult? Well ... let's say demanding of progressively greater investment of
effort and care the further one departs the smtp-norm, yes.
But for the few who DO want Exim to turn on a coffee maker, flash alarm lights,
reboot a machine, run a complex analysis toolset every 413th message - perhaps
that SHOULD be a bit less easy.
> Will this
> break some major users setup enough for them to switch away?
>
Almost certainly 'break' a few. But none at all beyond repair.
And the comfort that said repairs/alterations will have led to a less easily
compromised environment is more likely to retain current, and attract new
*professional* or DO-give-a-damn implementers is a Very Good Thing.
Anyone it 'drives away' is likely to be an instant-gratification dilettante. No
shortage of replacements for those.
JM2CW, but I am *happy* doing the OpenBSD-style mount changes, more careful
group setup, closer inspection of privs, et al.
Those protect a great deal more critters, and against a great many more dangers,
than just a possibly compromised Exim.
I am happier yet that the devel team are not only working on improvements, they
ARE taking 'breakage' into account.
But there is a limit to how far any volunteer team can - or should - carry the
careless or lazy. You wants 'turnkey' mail, you signs up for a 'major provider'
account.
One doesn't HAVE to be paranoid to appreciate an elevation in the level of
confidence in the system that allows more free time for the rest of one's
life... wine, 'significant (or not) others', song ... food..
