Συντάκτης: W B Hacker Ημερομηνία: Προς: Graeme Fowler Υ/ο: exim-dev Αντικείμενο: Re: [exim-dev] What user should ${run...} in config file run as?
Graeme Fowler wrote: > On Mon, 2010-12-13 at 10:15 +0000, David Woodhouse wrote:
>> It will drop privs when run as a dæmon, and it *cannot* get them back.
>
> That's what I was expecting.
>
>> It doesn't work like that. You cannot *gain* root privs; you can only
>> give them away if your process was started with them.
>>
>> So what it does is fork and exec a *new* Exim process to do the
>> delivery. That version of Exim doesn't drop privs.
>
> Aha, now my poor little dumb brain understands: the "missing link", as
> it stands, is the setuid bit on the Exim binary.
Removed (here). No harm (here). >
> 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).
>
Perhaps an 'edge case' - and bigtime, but *here* we don't ask Exim to deliver
messages to UID:GID other than its own.
All of our users are virtual, ergo HAVE NO system UID:GID.
CAVEAT1: Needs care in how the POP/IMAP service runs as well. MUCH care.
CAVEAT2: This is only the most obvious, and perhaps most widely-depended upon
thing that would change. MANY folks DO allow shell-account holders to (also)
have mail under the same UID:GID. As easy as it is to use virtual instead (AND
decouple shell login-ID and email ID to better secure BOTH), that still will not
change.
There will be other reasons.
> To cut to the chase (I hope I'm not really as dumb as I make out): are
> we looking at a significant architectural change here, really? It
> strikes me that having a single binary responsible for everything is a
> bit of a limiting factor in terms of risk management, especially given
> the setuid nature of the installation.
We are in F/LOSS -land.
Have a look at Sam Varshavchik's rationale as to why courier-mta is so 'modular'.
> If we separated out the local
> delivery process (for example) to be a binary in and of itself then the
> potential for exploitation is reduced.
>
True. And less convenient w/r config, flexibility, and doing the odd stuff.
Courier-mta sticks more closely to smtp, stricter RFC compliance, and NOT being
a toolset to gratuitously enable disregarding whatever-the-Hell the admin
chooses to do differently. Which, for better or worse, is what many of us
*want*. Exim makes it easier, so ....
> Yes, I know that's no small undertaking.
>
> Graeme
>
Not hard. Just tedious.
EITHER Exim OR courier-mta can be made to onpass to a DBMail back-end mailstore,
for example. BTDTGTTS.
The 'why' of it that is a different saga.... Think 'former SQL addict'.
