Re: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail

On Tue, Jan 16, 2007 at 02:42:17PM +1100, Bruce Evans wrote:
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).

Interesting. I was sure it won't work as you described, because the
target file can be a symlink and open(2) by default follows symlinks.
I thought that you just forget about O_NOFOLLOW flag, but it seems, that
with O_EXCL open(2) doesn't follow symlinks so it will work.

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.

That's true. Dirk's proposal is to create a file with mktemp(1) in the
same directory where we're going to rename(2) the file, but I don't
think mktemp(1) will be safe here:

good-guy attacker-within-a-jail

cd /jail/var/log
mktemp foo.XXX
rm -f foo.XXX
ln -s /etc/spwd.db foo.XXX
copy /path/to/jail_console.log foo.XXX
mv -f foo.XXX console.log

--
Pawel Jakub Dawidek http://www.wheel.pl
pjd@xxxxxxxxxxx http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!

Attachment: pgpDi2JGuoaUo.pgp
Description: PGP signature

Relevant Pages

  • Re: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail
    ... the "open" syscall. ... forced unlink() followed by an open. ... copying to move across file systems and there is no way to control this. ... Changing the target to a symlink to a directory on a different file ...
    (FreeBSD-Security)
  • Re: Setting up automatic delete
    ... On 2003-12-03, Ivan Rayner wrote: ... > is a symlink and if it is, to unlink the symlink itself. ... > then either unlink the hardlinked file or rename it back to the original and ...
    (comp.sys.sgi.admin)
  • Re: HEADS UP: Re: FreeBSD Security Advisory FreeBSD-SA-07:01.jail
    ... still follow a symlink if one is created between the "unlink" syscall and ... the "open" syscall. ... /* remove existing destination file name, ...
    (FreeBSD-Security)
  • Re: fstat() and symlinks
    ... MR>> symlinks: unlink and readlink. ... MK> Also: rename() and lchown. ... There can be many of them, but they are explicitly designed to avoid symlink ...
    (comp.unix.programmer)
  • RE: sym links
    ... It is not allowing me to "unlink" the symlink. ... I can try to wean them on to another ftp client, ...
    (freebsd-questions)