From owner-freebsd-security Tue Feb 24 08:30:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA26246 for freebsd-security-outgoing; Tue, 24 Feb 1998 08:30:35 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns.frihet.com (root@frihet.bayarea.net [205.219.92.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA26214 for ; Tue, 24 Feb 1998 08:30:18 -0800 (PST) (envelope-from tweten@ns.frihet.com) Received: from ns.frihet.com (tweten@localhost [127.0.0.1]) by ns.frihet.com (8.8.8/8.8.8) with ESMTP id IAA03017; Tue, 24 Feb 1998 08:02:35 -0800 (PST) (envelope-from tweten@ns.frihet.com) Message-Id: <199802241602.IAA03017@ns.frihet.com> X-Mailer: exmh version 2.0.1 12/23/97 To: Cy Schubert - ITSD Open Systems Group cc: Robert Watson , freebsd-security@FreeBSD.ORG Subject: Re: Find, Rm, and Root's Crontab Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Feb 1998 08:02:34 -0800 From: "David E. Tweten" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk 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. 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? -- 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