Re: Linux patches to solve /tmp race problem

From: Donaldson, Matthew (matthewat_private)
Date: Wed Apr 25 2001 - 21:35:28 PDT

  • Next message: Ariel Waissbein: "Re: OpenSSL-0.9.6a has security fixes"

    Chris Wright writes:
    >
    >After reading the explanation of your work, I missed how you can actually have
    >global data in the /tmp directory.  For example, /tmp/.font-unix or
    >/tmp/.X11-unix.
    >
    
    Currently, there is no way to have global /tmp data.  This may prove to be a
    problem - I'd be interested to know how many programs out there actually
    require /tmp data shared between users.  IMHO, sharing files via /tmp between
    users is not good practice anyway, and encourages security holes, but that's
    another story.
    
    For things that honour TMP or TMPDIR, you may be able to get away with
    setting these variables to a new /tmp-link shared directory, before running
    the program(s) that need it.  For things like X that make directories in
    /tmp, you can use symlinks to point to this shared directory.  More on that
    later for X specifically.
    
    Now you might say, "hey you're making a shared directory - now we've got our
    tmp race problem back again".  Which is true in a way, but with the following
    (important) improvements:
    
    1. we know which programs are using it, because we made them use it
    2. we may have the opportunity of setting permissions so that only the two
       users involved can use it
    
    #2 could be done using a shared group, or ACLs at such time as they are
    incorporated into the kernel.  If root and another program need to share
    a directory, you could even go further, particularly if it involved root
    writing to the directory, then the normal user reading it.  In that case
    you can write a wrapper that does this:
    
    * chowns the shared dir to root and stops the other user writing to it
    * runs the real program
    * chowns the shared dir to the normal user
    
    I'm not saying any of these solutions are particularly nice, but (hopefully)
    the number of programs needing such things is small.  The big benefit is that
    you know that no programs are going to be creating files in a shared /tmp
    directory unless you have specifically organised for it to happen.
    
    Note that as root you can portably make links in other people's /tmp
    using something like this:
    
    su - $user -c 'ln -s file1 file2'
    
    You can copy stuff from root's /tmp to a user's using either
    
    tar cfP - $dir | su - $user -c 'tar xfP -'
    
    or even for a file (if you don't care about permissions etc)
    
    cat $file | su -c $user -c 'cat > $file'
    
    Anyway, getting back to X, you can fix the /tmp/.X11-unix problem by
    creating a new directory for the socket, and creating symlinks in the
    /tmp directories of users that want it, called .X11-unix, and pointing
    to this directory.  If you are running xdm or gdm or the like, a good
    place to do this is the GiveConsole (a.k.a. gdm's PreSession/Default)
    script.  You can also get away with making this .X11-unix directory mode 700
    and chowning it to the user that is logging in, in the same manner as
    /dev/console is chowned.  The .font-unix stuff can be fixed by using
    localhost:7100 as a font path instead of unix:-1.  Using this doesn't seem
    to lead to any noticeable performance hit.
    
    For a detailed description of how I got X going, look at
    http://www.datadeliverance.com/docs/symlink-X11.html
    
    Cheers
    
    		-Matthew
    
    --
    +--------------------------------------------------------------------------+
    | Matthew Donaldson             http://www.datadeliverance.com             |
    | Data Deliverance Pty. Ltd.    Email: matthewat_private         |
    | 30 Musgrave Ave.              Phone: +61 8 8265 7976            _        |
    | Banksia Park                  Fax:   +61 8 8265 0032     John  / \/      |
    | South Australia 5091                                     3:16  \_/\      |
    +--------------------------------------------------------------------------+
    



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