From owner-freebsd-arch Sat Sep 2 15: 7: 8 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 6B82937B422; Sat, 2 Sep 2000 15:07:05 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id SAA61021; Sat, 2 Sep 2000 18:07:04 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 2 Sep 2000 18:07:04 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Ben Smithurst Cc: arch@FreeBSD.org Subject: Re: setuid ssh should die (Re: Request for review: nsswitch) In-Reply-To: <20000902225849.R72445@strontium.scientia.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 2 Sep 2000, Ben Smithurst wrote: > Robert Watson wrote: > > > Instead, either perform the open() directly to check, or make use of the > > access() syscall. > > Would this be the same access() whose manual page clearly says: > > CAVEAT > Access() is a potential security hole and should never be used. I'd welcome correction here, but my understanding of this comment is that it refers to situations where access() is being used by the application to determine whether it should perform an activity. The gist of the comment is the same as I was suggesting: rather than trying to emulate kernel policy, just use it. I.e., don't access(), rather, open(). Otherwise race conditions can exist between the access check and the implementation of the operation. In kernel, VFS locking can provide atomicity guarantees between the check and the operation itself. In the case of a compound access statement, where multiple privileged operations will be performed and you'd rather give early warning of failure than fail nastily half-way through, access() is fine. I.e., access() is a hint mechanism to the user, rather than a protection mechanism. This is somewhat like some of the performance locking techniques, where you can ignore locks to improve performance in certain memory models, as you can read the value without atomicity guarantees before determining whether you want to pay the cost of locking, while maintaining safety. Correctness is maintained as the real check always occurs before harm is done, but performance or usability is improved. If there's another reason, I'd certainly be interested. I'd probably suggest correcting that comment to read that, if used improperly, it can be a security problem. But the same goes for write() :-). Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message