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

On Mon, 2010-12-13 at 16:44 -0500, Phil Pennock wrote:
> On 2010-12-13 at 21:39 +0000, David Woodhouse wrote:
> > On Mon, 2010-12-13 at 21:30 +0000, David Woodhouse wrote:
> > > > 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.
> >
> > Sorry, I didn't address that directly.
> >
> > I did ponder it briefly but didn't see how it could be done. Would you
> > also have a whitelist of what the *contents* of those macros can be? Or
> > can I still do '-DTLS=${run{/bin/chmod u+s /bin/bash}}' or something
> > similar if TLS is on the list?
>
> In this particular case, the macro would only ever really be in an
> .ifdef block, so not evaluated, but your point stands for the general
> case. I suspect it's a case of "don't shoot yourself in the foot".
>
> Another option is that we apply a default regex for permitted content of
> macros overriden, permitting empty and some simple strings, and let the
> admin specify a different regexp if needed. The "different regexp" can
> be a v2 feature, implemented if anyone ever actually asks for it.
>
> There are a whole bunch of standing regexps compiled at start-up, I see
> no harm in adding another.

I think allowing only no-content macros to be defined would be sane
enough. Let's not complicate it with a regex unless we really need to.

But this is distinctly non-trivial to implement. How are you going to
put the information into the config file that certain macros are OK? And
how are you going to process that information as early as we currently
calculate the trusted_config setting?

Perhaps a *build* time option with a colon-separated list of the macros
which are permitted to be defined (with no content)?

I'm still inclined to think that putting the macros into a config file
and using .include would be easier.

--
dwmw2