Date: Tue, 24 Feb 1998 09:19:21 -0800 From: Cy Schubert - ITSD Open Systems Group <cschuber@uumail.gov.bc.ca> To: "David E. Tweten" <tweten@frihet.com> Cc: Cy Schubert - ITSD Open Systems Group <cschuber@uumail.gov.bc.ca>, Robert Watson <robert+freebsd@cyrus.watson.org>, freebsd-security@FreeBSD.ORG Subject: Re: Find, Rm, and Root's Crontab Message-ID: <199802241720.JAA19354@passer.osg.gov.bc.ca> In-Reply-To: Your message of "Tue, 24 Feb 1998 08:02:34 PST." <199802241602.IAA03017@ns.frihet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> cschuber@uumail.gov.bc.ca said: > >Try the -delete flag of find. > > Perhaps I ought to read TFM next time ... Looks like this handles the rm > half of the root-find-and-rm security hole. > > The original explanation featured two problems. The rm problem is that it > follows directory symbolic links, even when find does not. Since find (as > used for junk file cleaning) calls rm with a full path, rather than a > current- directory-relative file name, a properly timed directory symbolic > link insertion (after found and before rm'ed) can cause root to delete an > unintended file. > > Since the find "-delete" option operates relative to find's current > directory, it seems to me it should completely handle that part of the > problem. Do you have any idea why the commented-out finds in /etc/daily > haven't been changed to use "-delete" instead of "rm -f {} ;\"? > > >It is not atomic so a race condition, though much smaller, still exists. > > Care to expand on that? What is the race, and how could a cracker exploit > it? The find documentation on "-delete" looks pretty safe to me. 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. Giving find a high priority would help but is no guarantee either. I suppose /etc/daily could be changed to use -delete and have a comment (warning) indicating that this is unsafe. > > 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? > -- > 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 > Those who make good products sell products; those who don't, sell solutions. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca Cy.Schubert@gems8.gov.bc.ca 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?199802241720.JAA19354>