From owner-freebsd-security Tue Mar 16 4:37:14 1999 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id AC6DC14FFC for ; Tue, 16 Mar 1999 04:37:09 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id EAA25868; Tue, 16 Mar 1999 04:36:46 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id EAA11058; Tue, 16 Mar 1999 04:36:45 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id EAA25960; Tue, 16 Mar 1999 04:36:44 -0800 (PST) From: Don Lewis Message-Id: <199903161236.EAA25960@salsa.gv.tsc.tdk.com> Date: Tue, 16 Mar 1999 04:36:44 -0800 In-Reply-To: Robert Watson "Re: ACL's" (Mar 14, 6:02pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Robert Watson , Wilfredo Sanchez Subject: Re: ACL's Cc: Thomas Valentino Crimi , freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mar 14, 6:02pm, Robert Watson wrote: } Subject: Re: ACL's } On Sun, 14 Mar 1999, Wilfredo Sanchez wrote: } > Is there any reason (other than "it always has been so") why users } > should be allowed to create hard links to files they don't own? } } This variation on the restriction theme seems quite promising. Off hand, } I don't know of any linking behavior in the base system that relies on } renaming files owned by other users (except rename, and that is a separate } syscall). Most of the database applications people are mentioning } (including news) probably remain within the scope of a single user, I } would guess? And a number of the attacks of interest are related to } setuid or other files owned by different users (specifically interesting } ones). It seems to address well my concern that users cannot revoke access } to a file. Now they can be sure that rename() or chmod() followed by } revoke() to address data files, and simply unlink to dispose of a setuid } file. Setuid is presumably only of interest on open() so continued access } to an already instantied setuid session is probably fine. } } Rename could be induced to look like a hard link by causing a system } crash/power failure at an appropriate point in the rename procedure, I } would guess. But that's probably not in the scope of the security } protections we're addressing at this point. :-) Rename would only be a concern in cases where one of the links to the file in question was located in a directory that was writeable by the user attempting to do the rename. I suspect that most users won't install their setuid executables in directories that someone else has write permission on. Plain files might also be of concern (in directories like /tmp), but in most cases the directory will have the sticky bit, preventing rename from working. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message