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