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.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:27:12 PDT