From owner-freebsd-security Fri Oct 11 7: 1:39 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 7D51437B401 for ; Fri, 11 Oct 2002 07:01:36 -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 8FEE443E8A for ; Fri, 11 Oct 2002 07:01:35 -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 g9BE1aCk033184 for ; Fri, 11 Oct 2002 10:01:36 -0400 (EDT) (envelope-from behanna@zbzoom.net) Date: Fri, 11 Oct 2002 10:01:30 -0400 (EDT) From: Chris BeHanna Reply-To: Chris BeHanna To: FreeBSD Security Subject: Re: access() is a security hole? In-Reply-To: <20021011185423.B12227-100000@gamplex.bde.org> Message-ID: <20021011094935.I86274-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 Fri, 11 Oct 2002, Bruce Evans wrote: > On Thu, 10 Oct 2002, David Schultz wrote: > > > Thus spake Peter Jeremy : > > > On 2002-Oct-08 17:23:35 -0400, The Anarcat wrote: > > > >Also, this means that the stat() manpage should also contains a > > > >similar section about its non-fd incarnations. > > > > > > I disagree. access(2) is specifically designed to allow setuid/setgid > > > programs to validate access rights based on the real uid/gid - but is > > > virtually impossible to use safely for this task because of the > > > inherent race conditions. > > > > No, access(2) is designed to allow NON-setuid programs to easily > > do sanity checks without opening a file or device right away. > > There's still a race condition, but it isn't typically a security > > threat when all you're trying to do is prevent the user from > > shooting himself in the foot. To use access() in a setuid program > > is usually an error. > > No, it was designed to be useful to setuid programs. Whether it > actually is useful is arguable. From the V7 manual: > > "The user and group IDs with respect to which permission is checked > are the real UID and GID of the process, so that this call is useful > to set-UID programs". > > 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. Yes, I know--there's a possible race between open() and fcntl(). Where there a way to get a mandatory readlock on a file without opening it, then that race would be removed. Or, perhaps a more workable solution is to add a flag to open() that locks the file at the same time it's opening it. I don't have time at the moment to look at the source to see how this might be implemented, but I think it's a reasonable idea. Once a process has the lock, it can call fstat() to determine if the real [ug]id (which it already knows) has permission to access the file in the desired manner. If not, close the file (implicitly dropping the lock). This whole mess should be encapsulated into its own procedure. For programs that modify ranges of a file, the interface gets slightly more complicated, as you need an flock structure to specify the range to lock (so that other processes aren't blocked by a whole-file lock). For those who are (justifiably) skittish about modifying open(), perhaps a new syscall with semantics such as open_and_lock() should be created. -- 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