From owner-freebsd-security Sat Mar 13 23:20: 2 1999 Delivered-To: freebsd-security@freebsd.org Received: from ints.ru (ints.ru [194.67.173.1]) by hub.freebsd.org (Postfix) with ESMTP id 6E68914DB0 for ; Sat, 13 Mar 1999 23:18:36 -0800 (PST) (envelope-from ilmar@ws-ilmar.ints.ru) Received: from ws-ilmar.ints.ru (ws-ilmar.ints.ru [194.67.173.16]) by ints.ru (8.9.2/8.9.2) with ESMTP id KAA06411; Sun, 14 Mar 1999 10:17:20 +0300 (MSK) Received: from localhost (localhost [127.0.0.1]) by ws-ilmar.ints.ru (8.9.2/8.9.1) with ESMTP id KAA15294; Sun, 14 Mar 1999 10:18:10 +0300 (MSK) Date: Sun, 14 Mar 1999 10:18:10 +0300 (MSK) From: "Ilmar S. Habibulin" To: Robert Watson Cc: Thomas Valentino Crimi , freebsd-security@FreeBSD.ORG Subject: Re: ACL's In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 13 Mar 1999, Robert Watson wrote: > BTW, I'd really like to get rid of hard links -- they allow users to > retain copies of setuid files after the owner thinks they are deleted. > I.e., user creates a hard link to /usr/sbin/somesetuidbin to > /usr/tmp/mytemp. Now the admin upgrades the machine, thinking they have > removed the risk of the now known buggy somesetuidbin. But hard links are the UFS ideology is suppose. In my MAC implementation i limit number of hard links to a file with MAC level more than zero. It was done with the same thought im mind, as yours about suidbin. I have to make sure that this file is zero deleted after unlinking. And if i have another copy - it doesn't unlink at all. ;-) So my proposal is - maybe we should limit number of hard links on some files? PS. Sorry for bad english. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message