Re: [exim] Restricting a user's email destinations?

On 14/07/2006 02:39, W B Hacker wrote:
> I understand what it *attempts* to accomplish.

...but by quibbling over it you're demonstrating that the obverse may be
true (from an understanding perspective). I've seen it in use, and it
*does* accomplish what it sets out to do, namely it prevents any user on
that system except the Exim user make outbound calls to port 25 on a
remote host. On a fairly generic web hosting platform it covers a
multitude of possible user sins by allowing very fine-grained control of
outbound mail; the system in question has been subject to an awful lot
of spam mastiness in the past because users insist on uploading scripts
(Perl, PHP) which don't sanitise input properly (or have many other
variant possibilities) and end up being abused by spammers.

> Server security would be required to also prevent disabling the rule, either by
> deletion, insertion of a pass or workaround earlier in the ruleset, or killing
> the process that runs the firewall.

All three options require root on the system (or privilege escalation).
In that case, all bets are off anyway - it would be relatively trivial
at that point to reconfigure almost any part of the system, Exim
included, to push email out. And killing "the process that runs the
firewall" would result in instant system death, being as iptables is
simply a userland interface to the kernel's netfilter functionality
(this being a Linux system). I suppose on other OSes things may be
different, but the same rule applies that if someone's "got root" you
might aswell either pack up and go home, or turn the machine off.

> Better if it were on an external firewall.

That I can agree with to a point, however where would you then run the
receiving MTA? Certainly not on the external firewall as it would then
become a bottleneck; also running another service on an external
firewall is loose, if not bad, design. In my opinion, obviously; other
opinions are available, and no doubt will be!

> It also does not block pointing to a far-end submission port, nor can we be
> certain that a distant server will not accept local delivery without auth on
> such a port.

I think Mike was simply pointing out the "default" case. Stating that it
doesn't do something it isn't designed to do is a rather fallacious
argument, IMO. It's easy to extend it to cover other ports (465,587).


Graeme