Date: Sat, 31 Mar 2001 13:16:56 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Paul Herman <pherman@frenchfries.net> Cc: Warner Losh <imp@harmony.village.org>, Bill Moran <wmoran@iowna.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: Security problems with access(2)? Message-ID: <Pine.NEB.3.96L.1010331131056.40815F-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.33.0103311945010.13408-100000@husten.security.at12.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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?Pine.NEB.3.96L.1010331131056.40815F-100000>