[20470] in bugtraq
Re: Linux patches to solve /tmp race problem
daemon@ATHENA.MIT.EDU (Michal Zalewski)
Thu Apr 26 19:46:10 2001
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.LNX.4.21.0104260555400.15740-100000@nimue.bos.bindview.com>
Date: Thu, 26 Apr 2001 06:08:51 -0400
Reply-To: Michal Zalewski <lcamtuf@BOS.BINDVIEW.COM>
From: Michal Zalewski <lcamtuf@BOS.BINDVIEW.COM>
X-To: "Donaldson, Matthew" <matthew@DATADELIVERANCE.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <15078.61650.196935.160361@localhost.localdomain>
On Thu, 26 Apr 2001, Donaldson, Matthew wrote:
> If each user has a separate /tmp directory, unwritable by anyone else,
> this is no longer possible, so far as I can see.
Just to let you know, there were a discussion about context-sensitive /tmp
solutions something approx. two years ago on BUGTRAQ, with two suggested
solutions (well, or "workarounds", as the solution is not to use /tmp in
insecure way):
- euid-sensitive /tmp pseudo-filesystem, redirected e.g. to ~/tmp
(do not know if there were any implementations, but that is
actually pretty neat idea to use fs driver similar to /proc)
- euid-sensitive operations to redirect /tmp in the same manner
(I even made some Linux 2.0 module do implement it; it was
called redtmp and should be somewhere in archives)
Both of them would break many programs, like X server-client connectivity,
as mentioned in this thread. One of suggested workarounds was to redirect
any operations that involve creating fs objects in per-user /tmp space,
and handle all others (namely attempts to open w/o O_CREAT, connect etc)
by doing lookup in per-user /tmp space, and, if not found there, in root
/tmp space. It causes some risk that can be avoided by properly setting
umask for root.
There are some possible issues with using ~/tmp, as well - not every user
has to have writable ~ directory, sometimes user home dirs are mounted via
nfs and that would cause additional load, and so on.
Moreover, it is hard to choose between using euid or uid for switching.
Using euid would probably break even more setuid programs. But using uid
would allow user to run setuid applications with /tmp redirected to a
directory which has no sticky bit, and to perform nasty attacks.
--
_______________________________________________________
Michal Zalewski [lcamtuf@bos.bindview.com] | [security]
[http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
=--=> Did you know that clones never use mirrors? <=--=
