> This is a _simple_ one to 'fix'. My personal belief is that if anyone > is at all concerned about /tmp explots, they will create a 'tmp' > directory within their home directory and then set the TMPDIR environment > variable to reference it. Most of the programs in use today will honor > it; and if you are worried about the general user on your system, add to > the system profile to set their TMPDIR (and I guess you could check for > the existance of it and create it if necessary). > > There are just too many issues to deal with in the /tmp exploits; and this > method removes them _ALL_. (Oh, just don't have your home dir executable > and your tmp dir world writable at least. :) Well, it sure as heck does not solve the problem for those programs that use mktemp() or some similar function on a string liek "/tmp/fooXXXXXX". It also does not fix the problem for daemons or setuid tools, which sure as heck should not be honouring TMPDIR at all. These are simply source code bugs, and they should be fixed. In OpenBSD we have fixed hundreds of these /tmp races. I do not believe there is a simple answer. And if someone does invent a magic solution later on that helps, it won't matter because by then we should hopefully have finished fixing the last of these programs. A person who codes a /tmp race into their code today is no different from a person who codes in a buffer overflow or who uses gets(). TMPDIR does not exist primarily for use as a workaround to a serious and very common problem. (No problem should be "solved" by requiring each user to set an environment variable).
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:39:47 PDT