[8815] in bugtraq
Re: Postfix design directions
daemon@ATHENA.MIT.EDU (Wietse Venema)
Thu Dec 24 19:18:06 1998
Date: Wed, 23 Dec 1998 23:37:57 -0500
Reply-To: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
From: Wietse Venema <wietse@PORCUPINE.ORG>
X-To: perry@piermont.com
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <87zp8e7bju.fsf@jekyll.piermont.com> from "Perry E. Metzger" at
"Dec 23, 98 05:12:21 pm"
I agree. It feels like a defeat, using a set-gid program, but under
the current conditions, no hard-link games are acceptable.
The set-gidness is needed only to create the queue file, and
to delete it should the process receive a signal.
Wietse
Perry E. Metzger:
>
> Wietse Venema <wietse@PORCUPINE.ORG> writes:
> > I see two directions for Postfix evolution: 1) maintain the present
> > world-writable maildrop and unprivileged posting agent and 2) use
> > a protected directory and a set-gid posting agent (set-uid seems
> > to have no obvious advantage here). Is it feasible to keep maildrop
> > queue file names secret, and are the other attacks indeed mere
> > annoyances? Is it feasible to write secure set-gid programs that
> > are not only secure today, but that will be secure on tomorrow's
> > UNIX systems as well?
>
> The only thing that Postfix really needs is a tiny sgid program (about
> 20 lines in length) that reads a mail message on stdin and writes it
> out to a file in the mail drop directory -- and *only* into the mail
> drop directory, and *only* if the file doesn't exist yet (i.e. open
> with O_CREAT). The gid would be unique to the mail drop directory --
> breaking the ID would at best leave you with the ability to do the
> sorts of things you can do right now (i.e. nothing particularly
> mean). Because the program would be very small, it could be well
> scrutinized. Because it would be a gateway to microscopic privileges,
> it would be not-so-bad if it were broken.
>
> With this out of the way, Postfix would lose some edge condition
> problems it has now because of the world writable spool dir. This
> would not be a perfect fix, but it would be reasonably pragmatic.
>
> Perry
>
>
