Re: Postfix design directions

From: Richard Kail (e8903122at_private)
Date: Wed Dec 23 1998 - 14:52:45 PST

  • Next message: Savochkin Andrey Vladimirovich: "Re: Linux PAM (up to 0.64-2) local root compromise"

    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
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:26:15 PDT