Date: Wed, 25 Feb 1998 09:50:29 -0800 From: "David E. Tweten" <tweten@frihet.com> To: Cy Schubert - ITSD Open Systems Group <cschuber@uumail.gov.bc.ca> Cc: freebsd-security@FreeBSD.ORG Subject: Re: Find, Rm, and Root's Crontab Message-ID: <199802251750.JAA05503@ns.frihet.com>
next in thread | raw e-mail | index | archive | help
Concerning use by root of find -delete, cschuber@uumail.gov.bc.ca said: >A race condition can exist because the time it takes, however small, >between finding a file that should be deleted and issuing the >remove(3) or unlink(2) call. The instruction stream in find could be >interrupted and another process, possibly a process racing with find >to insert a symlink into the tree, could get control. If I'm not misreading the man page and if it is an accurate reflection of the code, that race should not be a problem. Of "-delete", the man page says, "This executes from the current working directory as find recurses down the tree. It will not attempt to delete a filename with a ``/'' character in its pathname relative to "." for security reasons." Since the current working directory is held as an inode, not as a path, "-delete" should not be able to get out of sync with the rest of find, even if someone inserts a symbolic link into the path to the current working directory. It still looks safe to me. >I suppose /etc/daily could be changed to use -delete and have a >comment (warning) indicating that this is unsafe. The unsafety warning currently exists. The problem is just that the commented-out code is even less safe than it has to be. If others (like me) uncomment the code, they shouldn't get code that is more dangerous than it has to be to provide the functionality they desire. Initially quoting me, cschuber@uumail.gov.bc.ca continued: >>Of course, all this still leaves find vulnerable to confusion while working >>its way back out of a path that's been changed since find entered it. That >>part should be fixed in find. Is anybody working on it? > >How can find guarantee that the directory tree hasn't changed since it entered >it? Find can't guarantee that a path won't change. It can guarantee that it won't get confused. It could build a stack of name-inode-device combinations on its way into a path, and compare the current inode-device pair after each chdir(".."). If the pairs are different, find need only cd into the deepest directory it can, above the one it wants, and continue business. Actually, using "-delete", even this measure may not be absolutely necessary, since delete works from find's current working directory. The exploit discussed in the original Chris Layne e-mail depends upon find and rm disagreeing over which inode-device pair corresponds to the path leading to find's current working directory. Since -delete works out of find's current working directory, that difference of opinion is impossible. It still might be a good idea for find to use the stack I mentioned above, if only to be able to "-print" out the right path names. If my analysis is correct, after changing /etc/daily's commented-out find commands to use "-delete" instead of "-exec rm -f {} \;" the comment characters should simply be removed. It seems "find ... -delete" is safe. -- David E. Tweten | 2047-bit PGP fingerprint: | tweten@frihet.com 12141 Atrium Drive | E9 59 E7 5C 6B 88 B8 90 | tweten@and.com Saratoga, CA 95070-3162 | 65 30 2A A4 A0 BC 49 AE | (408) 446-4131 "Take my wife, please." Henny Youngman (1906-1998) May he rest in peace. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802251750.JAA05503>