From owner-freebsd-hackers Sat Mar 31 11:54:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from clmboh1-smtp3.columbus.rr.com (clmboh1-smtp3.columbus.rr.com [65.24.0.112]) by hub.freebsd.org (Postfix) with ESMTP id 7D6E837B719; Sat, 31 Mar 2001 11:54:12 -0800 (PST) (envelope-from wmoran@iowna.com) Received: from iowna.com (dhcp065-024-023-232.columbus.rr.com [65.24.23.232]) by clmboh1-smtp3.columbus.rr.com (8.11.2/8.11.2) with ESMTP id f2VJpQw07259; Sat, 31 Mar 2001 14:51:26 -0500 (EST) Message-ID: <3AC644B1.1BB56BB3@iowna.com> Date: Sat, 31 Mar 2001 15:57:21 -0500 From: Bill Moran X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-RC i386) X-Accept-Language: en MIME-Version: 1.0 To: Robert Watson Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Security problems with access(2)? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thanks for the additional explanation. It has done a number of things for me, one of which is convince me that (for my application) the use of access() is not a security problem. I'm going to put together a suggestion for the doc team on this. I think it can probably be explained a little better in the man page. The current message is a little harsher than needed (I think) -Bill Robert Watson wrote: > > On Sat, 31 Mar 2001, Paul Herman wrote: > > > On Sat, 31 Mar 2001, Warner Losh wrote: > > > > > In message <3AC60925.7CF191FA@iowna.com> Bill Moran writes: > > > : I'm a little confused here, if access() is such a serious security > > > : problem that it should _never_ be used, do we now have a major problem > > > : with a large amount of software in the base system? > > > > > > Access(2) can be raced. > > > > Shouldn't the stat(2) manpage then also carry the same warning that > > access(2) has (apparently dating back to 4.4BSD-Lite)? ...or maybe > > even a suggestion to use fstat(2) instead... > > Well, really the moral of the story here is that userland applications > should allow the kernel to perform the access checks, rather than doing so > themselves. Any time you start replicating kernel security policy in the > userland application, you limit the ability to globally change policy by > modifying the kernel (for example, introducing ACLs, MAC, ...). Generally > speaking, where possibly, applications should attempt an activity rather > than try to determine if they would succeed if they tried. An example of > this is as follows: sshd, rather than binding port 22 when it starts, > looks at the uid to see if, theoretically it could. This means that if we > introduce a model that permits binding of port 22 by processes running > without uid 0, sshd has to be modified. > > It is safe to use access() and related functions to generate cleaner > failure modes, they just shouldn't be relied upon for security itself. > For example, you might call access() on a series of files to generate a > nice clean failure mode for a compound operation (so you don't have to > back out parts of the operation if a failure is received later), but then > still rely on the kernel to enforce protections by setting the effective > uid/gid and trying it. > > Most of these system calls are "safe", but only if you understand what > they do and how it differs from what you want. One thing we (TrustedBSD > Project) have been considering is introducing a "SECURITY CONSIDERATIONS" > section to mdoc(5) which would document things like common security issues > with the system call, correct use, etc. > > Robert N M Watson FreeBSD Core Team, TrustedBSD Project > robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message