Date: Tue, 16 Jan 2007 14:42:17 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Dirk Engling <erdgeist@erdgeist.org> Cc: freebsd-security@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org>, Colin Percival <cperciva@freebsd.org> Subject: Re: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail Message-ID: <20070116133259.N5056@delplex.bde.org> In-Reply-To: <45AC35A6.7090103@erdgeist.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070116133259.N5056>