From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Viro To: 9fans@cse.psu.edu Subject: Re: [9fans] correcting old failures, and NJ vs MA In-Reply-To: <87het8uxcl.fsf@becket.becket.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Thu, 11 Oct 2001 00:27:00 -0400 Topicbox-Message-UUID: 053b68c0-eaca-11e9-9e20-41e7f4b1d025 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.