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>