From owner-freebsd-security@FreeBSD.ORG Tue Jan 16 03:42:36 2007 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 84F8516A40F; Tue, 16 Jan 2007 03:42:36 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id 48E0D13C45E; Tue, 16 Jan 2007 03:42:36 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout1.pacific.net.au (Postfix) with ESMTP id E2A325A0F48; Tue, 16 Jan 2007 14:42:19 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id BAFDC2743A; Tue, 16 Jan 2007 14:42:18 +1100 (EST) Date: Tue, 16 Jan 2007 14:42:17 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Dirk Engling In-Reply-To: <45AC35A6.7090103@erdgeist.org> Message-ID: <20070116133259.N5056@delplex.bde.org> References: <200701111841.l0BIfWOn015231@freefall.freebsd.org> <45A6DB76.40800@freebsd.org> <20070113112937.GI90718@garage.freebsd.pl> <45ABDC7C.6060407@erdgeist.org> <20070115210826.GA2839@garage.freebsd.pl> <45ABEEEE.4030609@erdgeist.org> <20070115220039.GB2839@garage.freebsd.pl> <45AC29EA.70009@erdgeist.org> <45AC2E9F.20901@freebsd.org> <45AC35A6.7090103@erdgeist.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-security@freebsd.org, Pawel Jakub Dawidek , Colin Percival Subject: Re: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 03:42:36 -0000 On Tue, 16 Jan 2007, Dirk Engling wrote: > Colin Percival wrote: > >> No. `cp -f` unlinks the existing file and creates a new file, but will >> still follow a symlink if one is created between the "unlink" syscall and >> the "open" syscall. > ... > You are right. Atomically in binary is not atomical enough. > > mv in its rename()-form will do the job, so we need to create a file in > . by mktemp and mv it to the real name when filled. install -S already implements this, but not robustly enough to be secure. It only creates the temporary file if the target doesn't already exists, so it is subject to the usual races otherwise. 'S' stands for "safe" (no-clobber), not secure, so this is reasonable. However, it can easily be made both safer (actually no-clobber) and securer by opening the file with O_EXCL and exiting if the file exists at the time of the open. Perhaps cp -f should do the same. (Both have paths where they do a forced unlink() followed by an open(). This open() can easily use O_EXCL). mv(1) can never be trusted to use its rename() form since it uses copying to move across file systems and there is no way to control this. mv(1)'s rewriting of "mv file dir" to "rename file dir/file" is also a problem (I keep rename(1) handy to avoid it). I haven't followed most of this thread so I don't know what the attacker can do here. Changing the target to a symlink to a directory on a different file system would exploit both of the problems in mv. Bruce