On 2013-06-03 at 12:20 -0700, Allen Bell wrote:
> My case in point today is having installed the latest version of Exim and
> finding that the directive placing "root" on the never list - cannot be
> overridden.
Let's tackle this in two parts: this specific problem that you
encountered and the wider philosophical point that you raise.
The "can't be overriden" part is a compile-time option to allow it to be
overriden.
It _used_ to be the case that an empty list was interpreted as
containing uid 0; that was a bug fixed by Philip Hazel on 2004-11-05.
If the version of Exim you are running is 8.5 years old, then you have
other issues.
The wider issue:
Now, there's also a question of what the "exim_user" can be, the user
that handles normal operations. It used to be the case that the
documentation could be ignored and folks could choose to set that to be
root. *I* am the person who decided to hard-code a check, at build and
at run time, to ensure it could not be root. I did so because every
time the situation came up, it was a security hole being created through
ignorance. As developers, we can't disavow all responsibility if misuse
is trivially easy and we're actively aware of the problem.
Lots of people *think* they know enough to decide what is safe to
perform as root, but experience shows (reality, not posturing) that very
few do. The few that do, understand systems well enough to be able to
read and edit C code -- this is a pre-requisite of understanding Unix
systems well enough to be able to make this call. From the patch to
NewStuff where the change was documented:
+ 7. It has always been implicit in the design and the documentation that
+ "the Exim user" is not root. src/EDITME said that using root was
+ "very strongly discouraged". This is not enough to keep people from
+ shooting themselves in the foot in days when many don't configure Exim
+ themselves but via package build managers. The security consequences of
+ running various bits of network code are severe if there should be bugs in
+ them. As such, the Exim user may no longer be root. If configured
+ statically, Exim will refuse to build. If configured as ref:user then Exim
+ will exit shortly after start-up. If you must shoot yourself in the foot,
+ then henceforth you will have to maintain your own local patches to strip
+ the safeties off.
I think that this is a very reasonable balance: I don't claim to know
your systems well enough to make a better call than you about how to
manage them, but I do claim that if you're going to use our software
(and affect our reputation if there's a security incident) then you'll
need to know how to disengage the safeties before you get to do
something which we *VERY* strongly discourage.
As Exim is open source, you have the freedom to patch, and the revision
with the change in is visible, the bug tracking the change is visible
(and refers to the revision) at
<
http://bugs.exim.org/show_bug.cgi?id=752> and so nothing is hidden. If
you want to shoot your systems in the feet, go ahead.
But when considering all the cases where folks have turned up on the
mailing-list with severe security problems caused by setting that
option, I have no regrets whatsoever about the call I made in moving the
ability from "configuration option" to "trivial patch needed to comment
out a few lines".
There are other cases and it's always going to be a judgement call, in
every case. If you don't like the judgement calls made by those of us
@exim.org then you have the freedom to fork, to maintain code yourself,
to pay someone else to maintain it for you or any other arrangement that
makes sense for your systems and your business. You can even question
the decisions we make, on our mailing-lists, and that's both fine and
healthy, although a modicum of respect for us volunteers would be
appreciated.
Oh, and if anyone wants us to reintroduce a scenario known to create
security holes for many people when they misconfigure, that's fine, but
I'll sort out a bill to pay for a lawyer to sort out the liability
insurance we'll need, and we will need payment of both the lawyer's fees
and money in escrow for drawing out the liability insurance payments
before I revert such changes.
Regards,
-Phil
