X-RDate: Wed, 11 Mar 1998 15:16:13 +0500 (ESK)
Date: Mon, 9 Mar 1998 10:59:10 +0100 (MET)
From: (Rogier Wolff) <R.E.Wolff@BitWizard.nl>
To: linux-security@redhat.com
Subject: [linux-security] Towards a solution of tmp-file problems.
Introduction.
------------
Every now and then a new "exploit" turns up of some program that uses
tmp files. The first solution was "sticky bits", but since links exist
(that's a LONG time), that solution is inadequate.
Discussion.
----------
The problem is that you put an object (link/pipe) in the place where
you expect a program to put its tempfile, and wait for another user to
open the tempfile. Usually a method can be found that would allow you
to gain access to rights of the user opening the tempfile.
Sometimes a program already checks for the existence of the file, and
creates it if its not there. This is not atomic, and cannot easily be
made secure. The standard trick is to create a symlink that you move
back and forth between the "expected" file name and some "storage
place". On operating systems, like HPUX and SunOS, this has a much
better than 50% chance of success because they have synchronous
directory updates. On operating systems that have an efficient buffer
cache, like Linux, the chances are much worse. But that won't save
your machine from someone gaining root access: the bad guys simply
write a program to try it 100 times.
The Unix philosophy is that things that should be easy also -=are=-
easy. So, a program that has setuid rights might need to be careful
not to give those rights away. A non-setuid program should not have to
worry about buffer overruns (you can crash the program, wow!). It
should similarly not have to worry about temporary files.
Solutions.
---------
1) Have a libc function that securely creates a file and passes a file
descriptor to that file.
2) Have all programs respect an environment variable $TMP that says
where to put temporary files. Make the distributions set this to
$HOME/tmp, and make the "create a user" script add that directory.
3) A special file system (option) that doesn't allow symlinks or
hardlinks to files that you don't own. This has been suggested in the
past.
4) A special "/tmp" directory, that's private for every userid.
Solution 1 is not really adequate: It doesn't solve the problem for:
- programs that use the "get me a temp file -=name=-" function.
- Shell scripts.
- programs that use their own algorithms to generate a temporary
file name.
Solution 2 doesn't really work for all existing programs. It doesn't
work for ad-hoc shell scripts.
Solution 3 has the problem is that it sometimes doesn't solve the
problem: can I create a symlink to a symlink? Can I then change the
second symlink (which can be on a "tolerant" filesystem!)?
Ad 4: Some have suggested a "special case" for the use in "/tmp". I
dislike special cases, and would prefer a general solution that is
also capable of solving this.
Suggestion.
----------
How about allowing symlinks with "variable expansion"? A /tmp that is
a symlink to /.tmp/$euid would do the trick. The kernel should
maintain a small set of these variables (euid, uid, pid) without
user-intervention. A general way of adding these variables on a
per-process basis would make this a much more general feature.
How about:
echo "cad_version 5.0" > /proc/self/variables
ln -s '/usr/cad_$cad_version' /usr/cad
Note that /proc/self is a symlink to /proc/$pid, it is no longer a
special case! I think that the general "process symlink" code should
be modified for this. This would allow NFS clients to process the
dynamic symlinks, allowing for more control, besides the fact that
then you can have an ignorant host serving a full-featured Linux host.
Questions.
---------
- Does this really solve the problem at hand?
- Do people find this general variable symlinks useful?
- Does anybody want to volunteer writing the code?
- Does anybody want to beta-test the written code?
- What would get more testing: a patch for 2.1.x or 2.0.x?
- How many people would get bitten by the functionality change
of symlinks with $s in them? Suggestions for another character?
Regards,
Roger Wolff.
--
If it's there and you can see it, it's REAL |___R.E.Wolff@BitWizard.nl |
If it's there and you can't see it, it's TRANSPARENT | Tel: +31-15-2137555 |
If it's not there and you can see it, it's VIRTUAL |__FAX:_+31-15-2138217 |
If it's not there and you can't see it, it's GONE! -- Roy Wilks, 1983 |_____|
--
----------------------------------------------------------------------
Please refer to the information about this list as well as general
information about Linux security at http://www.aoy.com/Linux/Security.
----------------------------------------------------------------------
To unsubscribe: mail -s unsubscribe test-list-request@redhat.com < /dev/null
