Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 13 Oct 2002 14:43:06 -0400 (EDT)
From:      Chris BeHanna <behanna@zbzoom.net>
To:        FreeBSD Security <security@freebsd.org>
Subject:   Re: access() is a security hole?
Message-ID:  <20021013143844.W86274-100000@topperwein.pennasoft.com>
In-Reply-To: <m3k7koud6v.fsf@mordack.codesourcery.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 11 Oct 2002, Ricardo Anguiano wrote:

> Benjamin Krueger <benjamin@seattlefenix.net> writes:
>
> > * Ricardo Anguiano (anguiano@codesourcery.com) [021011 09:39]:
> > > Chris BeHanna <behanna@zbzoom.net> writes:
> > >
> > > > On Fri, 11 Oct 2002, Bruce Evans wrote:
> > > > > Setuid programs should only use access() to check whether they will
> > > > > have permission after they set[ug]id() to the real [ug]id.  Non-setuid
> > > > > programs mostly don't need such checks.  They can just try the operation.
> > > >
> > > >     Perhaps the way to avoid the race is to open the file, lock it,
> > > > and *then* call access(), then close the file or proceed based upon
> > > > the result.
> > >
> > > What's wrong with opening the file, then using fstat to check the
> > > properties of the file associated with the file descriptor?

    If you're worried about the kinds of races to which access(2) is
vulnerable, then you *MUST* lock the file to prevent another process
from modifying it, and that lock must be mandatory.  open() and
fstat() do not close the hole.  You need open() with a mandatory lock,
then fstat(), then, if the uid/gid has permission, do with the lock
whatever the program logic requires, or else close the file, dropping
the lock implicitly.

> > And if you don't have sufficient permission to open the file?
>
> IMHO, then there was no point in making the access(2) call.  The
> problem exists when the process is running with elevated privileges.
>
> AFAIK, open(2) does not fail due to permission problems when run as
> root.  Thus, the need to check for the invoking user's permission to
> open the file.

    Correct.  In the case that the process has no permission to open
the file, the setuid/gid program merely closes it immediately.

> PS: Chris: postmaster@telstraclear.co.nz says you don't exist.

    Then it's misconfigured, as I quite clearly do.  Perhaps it was a
transient DNS problem.

-- 
Chris BeHanna                      http://www.pennasoft.com
Principal Consultant
PennaSoft Corporation
chris@pennasoft.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021013143844.W86274-100000>