Re: [exim-dev] Candidate patches for privilege escalation

On Mon, 2010-12-13 at 15:51 -0500, Phil Pennock wrote:
> I'm concerned about the -MC* case, with -C/-D options being passed down
> from a root-invoked Exim, reinvoking itself for delivery. Otherwise,
> looks fine to me.
>
> Perhaps, for the Exim-user case, we block -C and let the config file
> define a list of macros which can be overriden on the command-line with
> -D when the user is Exim? That way, things like -DTLS can be passed
> through safely.

Using -C is fine; you just have to use a config file that's in the
trusted list. I'll like consider that part solved with what I just
pushed.

The more interesting part is -D, surely? But can't you handle that by
creating a two-line config file which sets the macro and then
uses .include to pull in the *real* config file?

> I really am concerned that without this, we're going to break some
> working setups.

Well, let's not lose sight of the fact that we're *trying* to break
working setups. The Exim user creating their own config file with
'spool_directory = ${run{/bin/chmod u+s /bin/bash}}' works right now,
and we'd quite like it not to. It makes a mockery of the privilege
separation.

It's just a case of working out how much we *have* to break, and what
workarounds or alternative functionality we can offer to make sure
people don't lose out.

In order to make the privilege separation actually work properly, I
think it's acceptable to impose the minor inconvenience described above
for those who are currently using -C/-D options. If you can come up with
alternative suggestions which fix privsep and are *easier* to use, I'm
all ears...

--
dwmw2