From owner-freebsd-security Thu Jan 9 22:08:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA20952 for security-outgoing; Thu, 9 Jan 1997 22:08:26 -0800 (PST) Received: from bitbucket.edmweb.com (bitbucket.edmweb.com [204.244.190.9]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id WAA20947 for ; Thu, 9 Jan 1997 22:08:23 -0800 (PST) Received: from localhost (steve@localhost) by bitbucket.edmweb.com (8.6.12/8.6.12) with SMTP id WAA02779; Thu, 9 Jan 1997 22:06:56 -0800 X-Authentication-Warning: bitbucket.edmweb.com: steve owned process doing -bs Date: Thu, 9 Jan 1997 22:06:54 -0800 (PST) From: Steve Reid To: Warner Losh cc: freebsd-security@freebsd.org Subject: Re: Obvious fix for tempfile race conditions? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > : If I've got that much of it right, why not simply add a mount option > : to disable symlinks on a given filesystem? > Because it isn't needed? It is possible to safely remove file in /tmp > or other hostile grounds by using fchdir and comparing before and > after inode# and device# using stat and fstat. Just because it _can_ be done safely doesn't mean that it _is_ being done safely. Consider the problem with /etc/security in 2.1.x: the script redirected the output of several commands onto a temporary file in /tmp, but made no checks on that file before writing to it. Any user could predict the filename and create a symlink, causing /etc/security to write to any file on the system. An obvious problem, and one would expect a script named "security" to pay attention to such issues. I'd bet there are other, less obvious problems in other programs. Disabling symlinks in /tmp would greatly reduce a cracker's options.