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 <[EMAIL PROTECTED]> 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
> [EMAIL PROTECTED] NAI Labs, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
