From owner-freebsd-security Tue Mar 16 14:39:13 1999 Delivered-To: freebsd-security@freebsd.org Received: from beatrice.rutgers.edu (beatrice.rutgers.edu [165.230.209.226]) by hub.freebsd.org (Postfix) with ESMTP id 99F2D1551B for ; Tue, 16 Mar 1999 14:38:39 -0800 (PST) (envelope-from easmith@beatrice.rutgers.edu) Received: (from easmith@localhost) by beatrice.rutgers.edu (980427.SGI.8.8.8/970903.SGI.AUTOCF) id RAA11541; Tue, 16 Mar 1999 17:06:10 -0500 (EST) From: "Allen Smith" Message-Id: <9903161706.ZM11539@beatrice.rutgers.edu> Date: Tue, 16 Mar 1999 17:06:09 -0500 In-Reply-To: Robert Watson "Re: ACL's" (Mar 14, 8:04pm) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Robert Watson Subject: Re: ACL's Cc: freebsd-security@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mar 14, 8:04pm, Robert Watson (possibly) wrote: > The s/owned/writable by/ change suggested sounds reasonable also. I > update my request for broken features and/or security holes given this > change: > > link(thefile, newname) will succeed only if open(thefile, O_RDWR) would > have succeeded, and if open(newname, O_CREAT, 0) would have succeeded. > > In this manner, the following interesting behavior is restricted: > > a) Joe user may not hard link a setuid root binary mode 755 from /usr/sbin > to /usr/home/joeuser/privatebin, as they could not have opened the binary > for writing. > > b) Joe user may not hard link another users data file mode 644 in > /usr/home/samuser/patentapplication to /usr/home/joeuser/privatedata as > they could not have opened the data file for writing. > > The following behavior is not restricted: > > c) Joe user may hard link a data file they own in their home directory to > another name. > > d) Joe user may hard link a group-writable file in another user's home if > Joe user is in the group of the file. > > e) Root may hard link any file to any other file on the same partition. > > Through the addition of file system ACLs, this is really quite flexible. > > So we are still in search of any other real-world use that might be broken > as a result of the change. Might I suggest that an intermediary between "hard links unlimited" (the current case) and "hard links only if you can write the file" could be gotten by forbidding hardlinks to suid/sgid binaries, unless the user was: A. root; B. the user the suid was to; or C. a member of the group the sgid was to? This appears to minimize the risk of breakage. Normally, you'd be worried about a race between a supposed stat and the link, but since this would be a system call this isn't a worry except for multiprocessor systems (the vnode would need to be locked from the start of the stat to the end of the link). -Allen -- Allen Smith easmith@beatrice.rutgers.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message