From owner-freebsd-security Sun Oct 13 11:43:14 2002 Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38E6C37B401 for ; Sun, 13 Oct 2002 11:43:12 -0700 (PDT) Received: from topperwein.dyndns.org (acs-24-154-51-246.zoominternet.net [24.154.51.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EBB743EA9 for ; Sun, 13 Oct 2002 11:43:11 -0700 (PDT) (envelope-from behanna@zbzoom.net) Received: from topperwein.pennasoft.com ([192.168.168.10]) by topperwein.dyndns.org (8.12.6/8.12.5) with ESMTP id g9DIhBCk033892 for ; Sun, 13 Oct 2002 14:43:11 -0400 (EDT) (envelope-from behanna@zbzoom.net) Date: Sun, 13 Oct 2002 14:43:06 -0400 (EDT) From: Chris BeHanna Reply-To: Chris BeHanna To: FreeBSD Security Subject: Re: access() is a security hole? In-Reply-To: Message-ID: <20021013143844.W86274-100000@topperwein.pennasoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 11 Oct 2002, Ricardo Anguiano wrote: > Benjamin Krueger writes: > > > * Ricardo Anguiano (anguiano@codesourcery.com) [021011 09:39]: > > > Chris BeHanna writes: > > > > > > > On Fri, 11 Oct 2002, Bruce Evans wrote: > > > > > Setuid programs should only use access() to check whether they will > > > > > have permission after they set[ug]id() to the real [ug]id. Non-setuid > > > > > programs mostly don't need such checks. They can just try the operation. > > > > > > > > Perhaps the way to avoid the race is to open the file, lock it, > > > > and *then* call access(), then close the file or proceed based upon > > > > the result. > > > > > > What's wrong with opening the file, then using fstat to check the > > > properties of the file associated with the file descriptor? If you're worried about the kinds of races to which access(2) is vulnerable, then you *MUST* lock the file to prevent another process from modifying it, and that lock must be mandatory. open() and fstat() do not close the hole. You need open() with a mandatory lock, then fstat(), then, if the uid/gid has permission, do with the lock whatever the program logic requires, or else close the file, dropping the lock implicitly. > > And if you don't have sufficient permission to open the file? > > IMHO, then there was no point in making the access(2) call. The > problem exists when the process is running with elevated privileges. > > AFAIK, open(2) does not fail due to permission problems when run as > root. Thus, the need to check for the invoking user's permission to > open the file. Correct. In the case that the process has no permission to open the file, the setuid/gid program merely closes it immediately. > PS: Chris: postmaster@telstraclear.co.nz says you don't exist. Then it's misconfigured, as I quite clearly do. Perhaps it was a transient DNS problem. -- Chris BeHanna http://www.pennasoft.com Principal Consultant PennaSoft Corporation chris@pennasoft.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message