From owner-freebsd-security Sun Mar 14 17:25:58 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (Postfix) with ESMTP id C618815AB0 for ; Sun, 14 Mar 1999 17:25:47 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id UAA07633; Sun, 14 Mar 1999 20:25:27 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Sun, 14 Mar 1999 20:25:27 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Wilfredo Sanchez 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 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