Date: Sun, 14 Mar 1999 20:25:27 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Wilfredo Sanchez <wsanchez@apple.com> Cc: Thomas Valentino Crimi <tcrimi+@andrew.cmu.edu>, freebsd-security@FreeBSD.ORG Subject: Re: ACL's Message-ID: <Pine.BSF.3.96.990314201139.5121L-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.3.96.990314174217.5121K-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 14 Mar 1999, Robert Watson wrote: > 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 Needless to say, s/renaming/linking/ in the above line; my typing was getting ahead of my sentence. What I meant was that linking files owned by other users seemed to be unusual, except in renaming which is now supported by the rename() syscall instead. Just a (hopefully obvious) clarification. 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. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ 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?Pine.BSF.3.96.990314201139.5121L-100000>