Date: Fri, 07 Sep 2001 03:18:38 -0700 From: Dima Dorfman <dima@unixfreak.org> To: Chad David <davidc@acns.ab.ca> Cc: hackers@freebsd.org Subject: Re: ipfw and access Message-ID: <20010907101843.5E65A3E31@bazooka.unixfreak.org> In-Reply-To: <20010907003041.A61061@colnta.acns.ab.ca>; from davidc@acns.ab.ca on "Fri, 7 Sep 2001 00:30:41 -0600"
next in thread | previous in thread | raw e-mail | index | archive | help
Chad David <davidc@acns.ab.ca> wrote: > I was just wondering about the caveat in that access(2) man page > that says that access is a potential security hole and should > never be used, and the fact that ipfw calls it on line 2435. > > I seem to recall a discussion about this a few months ago, but > I don't really remember the details... and the irony of ipfw > calling a documented "should never be used" function got my > attention. > > Is this really a problem, or is the man page paranoid? The manual page is probably paranoid, but I don't think we should change it. It's very easy to abuse access(2). It's a potential security hole if you use it to provide access control. E.g., you're a setuid process, and you got a filename as an argument. You want to open it, but only if the user that called you has sufficient privileges to do so. Using access(2) on that filename and opening it if it returns success would be a security hole, because that file might've changed (mv, cp, chmod, whatever) between your call to access(2) and your call to open(2) (classic example of a race condition). The right thing to do would be to drop effective privileges to that of the user, and use open(2) directly. ipfw just wants to know if its last argument is a valid filename (see the first usage form in the manual page). I think that's a pretty legitimate use, although it shouldn't rely on the fact that the file will exist and/or be readable when it gets around to opening it. I.e., it should still handle a failed open gracefully--and it does. One can still trick it into trying to open a file that isn't there, but the results won't be any more spectacular than doing that to any other program (e.g., `cat /nonexistent`). Besides, ipfw isn't privileged. 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?20010907101843.5E65A3E31>