From owner-freebsd-hackers Sun May 6 20:50:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id EC15337B423; Sun, 6 May 2001 20:50:41 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f473oSf44022; Sun, 6 May 2001 23:50:28 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 6 May 2001 23:50:28 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Dag-Erling Smorgrav Cc: Alfred Perlstein , Dima Dorfman , "William E. Baxter" , hackers@FreeBSD.ORG Subject: Re: Getting peer credentials on a unix domain socket In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 7 May 2001, Dag-Erling Smorgrav wrote: > Alfred Perlstein writes: > > The silly part of it is that the socket's initial credentials > > might be different than the holder's credentials. > > That's a feature, just like you can open /dev/io as root, then drop root > privs and do direct I/O to your heart's content even if you're no longer > root. However, a lot of device drivers do checks on p->p_ucred (or indirectly via suser(p)) rather than using the cached credential in the struct file. This is arguably wrong or evil, but since the driver writers really feel like doing that, I suppose all we can do is shoot them, not stop them. There are actually a number of places in netinet and netinet6 where some checks are performed on so->so_cred while others are performed on p->p_ucred. This is to restrict the rebinding of sockets by processes, preventing the following scenario: (1) privileged process p1 creates socket s1, and binds it to (PF_INET, IPPROTO_TCP, 80) (2) privileged process p1 transfers s1 to unprivileged process p2 (or drops privileges) (3) unprivileged process p2 rebinds to (PF_INET, IPPROTO_TYPE, 22) Getting the checks for that right is hard, as the definition of correct is a bit ambiguous, and it's not clear all the code in there is "right" at this point. It's one of the things on the list of authorization components to review. Generally speaking, I'd much rather the cached credential was used, but understand why it's not in this scenario. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message