Re: [9fans] correcting old failures, and NJ vs MA

[Alexander Viro <viro@math.psu.edu>]

On Wed, 10 Oct 2001, Thomas Bushnell, BSG wrote:

> That's an important point that I think got lost.  For example, someone
> asks "what about find?  won't it miss stuff if you move a directory?"
> And the answer is "yes, it will--and it will miss stuff whether you
> move things with a quick syscall or with a long tedious file-by-file
> copy-and-delete."  

I don't recall anybody complaining about the stuff find _misses_. It's
stuff that it finds in places where it shouldn't have looked that is
a problem.

Let me try again: full-blow rename() makes several userland programs
simpler at the cost of many userland programs becoming much more complex
or outright broken.  It's not just the kernel complexity that goes up -
that can be done, even though result will not be nice.  It's userland
that really pays a lot and that's much harder to handle.

Symlinks are actually a nice example of the same effect.  Resulting kernel
complexity is nothing compared to complexity added to userland to prevent
symlink attacks.  Notice that correct tree-walker must reimplement a large
chunk of VFS if it's ever going to be used in the area writable to attacker.
Every time when tar(1) does open() it has to do very ugly stuff.  Example:
tar in Solaris 2.6 and GNU tar earlier than 1.12 [1] do stat() followed by
open().  Then they proceed to write the metadata from stat and data read from
file into the archive.  Think what will happen if file gets replaced with
symlink to /var/spool/mail/boss between the stat() and open() during the system
backup.  Yes, missing fstat().  But even putting fstat() there doesn't solve
the problem - we have to deal with the fact that open() on some devices
may have nontrivial side effects.  O_NDELAY removes most of them, but not
all.

Worse yet, _anything_ that does unlink("foo/bar") is open to an attack -
all "when should I follow the symlinks" logics applies only to the last
component.  And there's nothing kernel could do about that.  As the result,
anything that may be used in hostile environment has to reimplement
namei(9), doing the series of open()/fstat()/fchdir() just to walk the
friggin' path.  And you'd better have a working O_NOFOLLOW or do lstat()
first; otherwise things will get very ugly.

I wouldn't describe reimplementing namei() in a lot of basic utilities
as making the life easier for userland. YMMV.

[1] BTW, it's not just GNU or Sun being sloppy - that would be business
as usual, sad as it is.  OpenBSD pax(1) is vulnerable to exactly that
attack - there is a window between stat() and open() that can be used
to replace the file you own with a symlink to a file you should be
unable to read.  And yes, it _is_ exploitable.  Attack would take a
while, but potential results of getting a look at the contents of
right mailbox may be more than worth attacker's time and efforts.