Date: Tue, 16 Mar 1999 04:36:44 -0800 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Robert Watson <robert+freebsd@cyrus.watson.org>, Wilfredo Sanchez <wsanchez@apple.com> Cc: Thomas Valentino Crimi <tcrimi+@andrew.cmu.edu>, freebsd-security@FreeBSD.ORG Subject: Re: ACL's Message-ID: <199903161236.EAA25960@salsa.gv.tsc.tdk.com> In-Reply-To: Robert Watson <robert@cyrus.watson.org> "Re: ACL's" (Mar 14, 6:02pm)
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 14, 6:02pm, Robert Watson wrote: } Subject: Re: ACL's } On Sun, 14 Mar 1999, Wilfredo Sanchez wrote: } > 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. :-) Rename would only be a concern in cases where one of the links to the file in question was located in a directory that was writeable by the user attempting to do the rename. I suspect that most users won't install their setuid executables in directories that someone else has write permission on. Plain files might also be of concern (in directories like /tmp), but in most cases the directory will have the sticky bit, preventing rename from working. 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?199903161236.EAA25960>