Re: Anonymous Qmail Denial of Service

[vermont () GATE NET (Illuminatus Primus)]

On Mon, 4 Jan 1999, Wietse Venema wrote:

> What happens when the qmail-queue process is signaled with, say,
> SIGKILL? The file will stay in the queue. That's a zero-length
> file, owned by qmail, without any user identification whatsoever.

Signals are one of the many gateways between setid processes that
programmers can easily forget about.  An easy remedy for the signal
problem is to log the real uid on startup and then set it to the effective
uid before doing anything important.  This is probably what ping had to do
to fix the SIGALRM ping flood exploit.

In my opinion, though, the "preferable solution" is to not do setgid and
be happy that the ownership of the 0 byte files can be traced.  As you've
said yourself, set[ug]id offers too many avenues for exploitation.  The
supposed tightening of Postfix's security by using a setgid queue helper
seems to be unclean to me.  Will Postfix's queue daemon behave correctly
when queue files can be dropped in half-written (SIGKILL to the setgid
queue helper while its writing)?  Will the queue daemon behave correctly
if a queue file is left locked indefinetly (SIGSTOP or SIGKILL, depending
on how the lock is made)?  The only clear advantage you have over
Bernstein's method is that the first interaction with the queue atomically
logs the caller's uid.

I think it is far easier to implement secure enforcement of policy when
the privilege levels are more clearly separated than in setid.  Sending
the data through sockets is one way to accomplish this.  Check out userv:
http://www.chiark.greenend.org.uk/~ian/userv/

I'm sure implementing something similar that allows portable
authentication of uids wouldn't be that hard - I can think of several
schemes right now.