Re: [exim] Alternative to the -D option

On Mon, 2011-10-10 at 17:13 -0400, Phil Pennock wrote:
> Someone's already suggested using a "protocol" to deal with some
> problems. That's the -oMr flag.

I used -oMt in a similar manner. But ick.

> There's a proposal/patch which adds a ${getenv:...} expansion operator
> (or somesuch). That would not propagate cleanly to messages delivered
> by queue-runners started from another context, but might be useful in
> some conditions. Would it help with some of your current issues? I'm
> mostly in favour of adding ${getenv:...}. It does have some security
> impact, but the _results_ of getenv are not subject to string expansion,
> as macro results are (unless fed back through ${expand:...}) so is
> generally much MUCH safer.

I did have a couple of options in my previous email, but I deleted them
when I thought about exim's internal architecture. The problem is
complex and there are several ways of addressing it. I doubted I could
tell you guys who deal with it all the time anything new. But since you
asked ...

The perfect solution to all of my uses would be to only allow -D to be
set by trusted users (eg root). As the author of the exim.conf file
this means I don't have check the value of such settings. I can assume
they make sense because the came from a trusted source. But this is
obvious, and if it was easy it would have been done.

>From my knowledge of exim's architecture it spawns many sub-processes
and the difficulty is in communicating to those non-privileged
sub-processes that the -D was by someone you can trust. Maybe there is
some trick you can use, like creating a temporary read only file owned
the trusted user, unlink'ing it immediately, writing the trusted
settings to it, and passing the handle to the sub-process. The
sub-process can use fstat to verify the file was created a trusted
process. There is nothing much new in the process, as exim already
create lots of files with settings (eg acl's) it must trust in its spool
directories, so it is unlikely to create a security hole. There are no
messy cleanup issues - as the OS will clean up when the last handle
disappears. It's so transient I doubt the data will hit the disk.

The other option I though of was along the lines of what you suggest
with getenv. Again, it's an obvious thing to do, so obvious in fact
that that I went searching the spec for it as a work around. My guess
was it wasn't there because it wasn't portable to some platform. So
instead of that, since the -D option is going the way of the dodo,
instead I would just change the way it works. Provide a ${dopt{name}}
that returns the VALUE in -Dname=VALUE. Then migrating would just be a
case of "sed -i 's/\<name\>/${dopt{name}}/g' exim.conf".

As you noted, something that allows a non-privileged user to inject
random values does seem like a bit of a loophole, and since I don't need
to do that I personally prefer the "allow trusted users to set -D"
option. However, I can well imagine someone out there will have some
perfectly good reason for needing a normal user to pass information in.
In my case, since I write my own config, I doubt it would create a real
loophole, as I have security through obscurity. No one is even going to
know the names of the macros I use. If there is an issue, it will be
for well know configs like those packages with the distro's.

You could do both I guess. Ie have a ${dopt{name}} and
${dopt_unsafe{name}}, the first only returning macros set by trusted
users. The ability to do this is one advantage of something like
${dopt{...}} over ${getenv:...}.