Date: Sun, 14 Mar 1999 18:02:36 -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.990314174217.5121K-100000@fledge.watson.org> In-Reply-To: <199903142128.NAA10220@scv2.apple.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 14 Mar 1999, Wilfredo Sanchez wrote: > | BTW, I'd really like to get rid of hard links -- they allow users to > | retain copies of setuid files after the owner thinks they are deleted. > | I.e., user creates a hard link to /usr/sbin/somesetuidbin to > | /usr/tmp/mytemp. Now the admin upgrades the machine, thinking > they have > | removed the risk of the now known buggy somesetuidbin. > > 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. :-) So, does anyone have any examples of situations handled incorrectly/badly by allowing only the owner of a file to link() it? 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.990314174217.5121K-100000>