Date: Sat, 31 Mar 2001 15:57:21 -0500 From: Bill Moran <wmoran@iowna.com> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Security problems with access(2)? Message-ID: <3AC644B1.1BB56BB3@iowna.com> References: <Pine.NEB.3.96L.1010331131056.40815F-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AC644B1.1BB56BB3>