From owner-freebsd-security Fri Oct 11 20:11:32 2002 Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08CF337B401 for ; Fri, 11 Oct 2002 20:11:30 -0700 (PDT) Received: from HAL9000.homeunix.com (12-232-220-15.client.attbi.com [12.232.220.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DC3C43E6A for ; Fri, 11 Oct 2002 20:11:29 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id g9C3BLbb001986; Fri, 11 Oct 2002 20:11:21 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id g9C3BKLX001985; Fri, 11 Oct 2002 20:11:20 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Fri, 11 Oct 2002 20:11:20 -0700 From: David Schultz To: Don Lewis Cc: peterjeremy@optushome.com.au, behanna@zbzoom.net, security@FreeBSD.ORG Subject: Re: access() is a security hole? Message-ID: <20021012031120.GA1951@HAL9000.homeunix.com> Mail-Followup-To: Don Lewis , peterjeremy@optushome.com.au, behanna@zbzoom.net, security@FreeBSD.ORG References: <20021011212020.GA209@server.c18609.belrs1.nsw.optusnet.com.au> <200210120202.g9C220vU046809@gw.catspoiler.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200210120202.g9C220vU046809@gw.catspoiler.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thus spake Don Lewis : > > It's not at all clear how to solve this in userland. In the absence > > of symlinks, you can parse the pathname, using open(),fstat(),fchdir() > > to securely get to the final pathname component. Unfortunately, > > there's no way to securely do this and handle symlinks (because you > > have to use lstat() to detect a symlink and there is a gap between > > the lstat() and subsequent open(). > > It's worse than that because you can run into the same problems with > trying to verify the directory permissions before doing mkdir(), > rmdir(), link(), symlink(), etc. In addition to what has already been mentioned, consider what happens when someone creates a symlink to a tape drive. Just the act of opening the device may have actions associated with it. Really, there ought to be a version of the open syscall that takes an argument specifying the credentials to use for the call, but instead we're stuck with the lovely setuid suite of functions. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message