[8827] in bugtraq
Re: Postfix design directions
daemon@ATHENA.MIT.EDU (Richard Kail)
Thu Dec 24 22:12:11 1998
Date: Wed, 23 Dec 1998 23:52:45 +0100
Reply-To: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
From: Richard Kail <e8903122@STUDENT.TUWIEN.AC.AT>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <19981222200230.6E97245901@spike.porcupine.org>
Hello !
On Tue, 22 Dec 1998, Wietse Venema wrote:
> 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?
Take a look on the philosophical aspect of the matter. What you adress
here is that you need a interface between a system service (mail) and a
user program. The system service requires some kind of special
privilegies, the user program shoudn't have any of them.
What you want is to "narrow" the impact of the action of the user to the
system service down to a very well defined, restricted path. For every
solution you should look where the "narrowing" happens. With this I mean
the place, construction etc. where you have to control the input of the
user (or the network etc.).
A world writeable directory scanned by some kind of program is only one of
many ways to build a interface between the user ('s programs) and a system
service. World writeable directories are IMHO a very rough way and gives
you not very much control of what can happen. The narrowing-point is where
you scan the dropped files in this directory. This may work, but you leave
a directory world writeable, which may be not a good idea. I think it
isn't a good idea to grant privileges under users control before you do
the "narrowing".
If Setuid/setgid-programs are done right, you have the "narrowing" before
you may use special privileges. You are very right that the problem with
setuid/gid programs is that it is possible for the user to control parts
of the environment under which the program runs.
On unix systems there are other ways to do interfacing between the user
('s programs) and a system service. There are named pipes, message queues,
shared memory, sockets, ... you know them better than I do. Fortunately,
there seems to be a protocol for exchanging mail via sockets, so you don't
have to do it twice.
Why not take the socket-approach to build the communication between the
users program and the system service ? You will have more control as with
setuid/gid programs, because the system administrator will determine the
environment in which the privileged program runs and you have not more
problems with narrowing as you already have for the network (e.g. SMTP)
support.
Ok, you may tell me that you want that your mail system works also without
network support. Wouldn't it be possible to use SMTP over a
file-system-namespace-socket ?
Kind regards,
Richard
------
Duct tape is like the force. It has a light side, and a dark side, and
it holds the universe together ... -- Carl Zwanzig
