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>