[371] in linux-security and linux-alert archive
Re: elm and /tmp/mbox.*
daemon@ATHENA.MIT.EDU (Zefram)
Tue Sep 19 15:04:45 1995
From: Zefram <A.Main@dcs.warwick.ac.uk>
To: sizif@botik.ru (Yury Shevchuk)
Date: Tue, 19 Sep 1995 00:39:59 +0100 (BST)
Cc: linux-security@tarsier.cv.nrao.edu
In-Reply-To: <m0suZpG-000CkVC@hole.botik.yaroslavl.su> from "Yury Shevchuk" at Sep 18, 95 10:37:00 am
>>This is a more general problem. Any program creating files in /tmp (not
>>just elm) can cause the same problem if someone knows the name of temp
>>file in advance and creates a symlink under that name. It would be nice
>>to have a way to prevent creating symlinks in /tmp. The setuid bit on
>>directories is not used for anything - maybe it could be used for that?
>>If it is set, no one except root and the owner of the directory can
>>create symlinks in it. This works even for very old programs which
>>don't know anything about symlinks and lstat(). It shouldn't be too
>>hard to implement in the kernel. Comments?
I think it's excessive. Shell scripts that put temporary files in /tmp
are unlikely to be fully safe any other way, but they generally don't
check to see if they're writing into an existing file anyway.
>Even simpler: since symlinks in *any* world-writable directory are
>security holes, we'll do good by just prohibiting symlinks if
>(dir_mode & 0x2).
Bad idea. Symlinks are useful; they should definitely not be
implicitly prohibited anywhere. Practical example: a world-writable
directory acting as a link farm to image files. Under Marek's proposed
semantics (re setuid bit on the directory), the owner of the directory
would not want to prohibit symlinks, and there would be no security
problem with this.
>This might seem a bit too quick, but there are precedents: setuid
>shell scripts are disabled in Linux for security reasons. So why not
>disable symlinks in world-writable directories as well?
I was under the impression that setuid shell scripts were not supported
on Linux because (a) it makes the exec code a bit simpler and (b)
they're a really bad idea, so you don't lose anything by not supporting
them. Security reasons lead one to not create setuid shell scripts,
not to remove support from the kernel.
Has anyone noticed the way to avoid the symlink problem on existing
systems? An open(2) with the O_EXCL flag will fail with EEXIST on just
about any Unix if the pathname it is given is a symlink, regardless of
whether or not it points to anything. mkdir(2) is similarly immune to
symlinks. creat(2) is vulnerable, because the open() call it is
equivalent to has the flags O_CREAT|O_TRUNC but not O_EXCL. So to
create a temporary file without incurring the symlink problem (or
risking splatting someone else's file if you're root), use O_EXCL, and
check the return code. I'm not sure how well this will behave over
NFS, but who has a non-local /tmp?
In the case of Elm, it is broken by design, and O_EXCL is of limited
use. (A trivial denial-of-service attack will still work.) It needs
to put its temporary file in a directory writable only by the user. A
possible way to do this (other than using home directories) is to
create a directory under /tmp for each user, and not delete them. This
would allow any program that knows about the arrangement to have a
(relatively) safe directory for temporary files.
-zefram
