Date: Tue, 16 Mar 1999 17:06:09 -0500 From: "Allen Smith" <easmith@beatrice.rutgers.edu> To: Robert Watson <robert@cyrus.watson.org> Cc: freebsd-security@FreeBSD.ORG Subject: Re: ACL's Message-ID: <9903161706.ZM11539@beatrice.rutgers.edu> In-Reply-To: Robert Watson <robert@cyrus.watson.org> "Re: ACL's" (Mar 14, 8:04pm) References: <Pine.BSF.3.96.990314201139.5121L-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9903161706.ZM11539>