From owner-freebsd-arch Wed Jun 27 12:54: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 3FDEC37B401; Wed, 27 Jun 2001 12:54:02 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: from hornet.unixfreak.org (hornet [63.198.170.140]) by bazooka.unixfreak.org (Postfix) with ESMTP id D392C3E31; Wed, 27 Jun 2001 12:54:01 -0700 (PDT) To: Robert Watson Cc: arch@freebsd.org Subject: Re: Peer credentials on a Unix domain socket In-Reply-To: ; from rwatson@freebsd.org on "Wed, 27 Jun 2001 15:19:52 -0400 (EDT)" Date: Wed, 27 Jun 2001 12:54:01 -0700 From: Dima Dorfman Message-Id: <20010627195401.D392C3E31@bazooka.unixfreak.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Robert Watson writes: > > How does this solution compare with similar solutions on other platforms? NetBSD has an equivilent of our SCM_CREDS (they call it UNP_WANTCRED); I'm not aware of any similar functionality in OpenBSD; and I've been told, but haven't confirmed myself, that Linux has an SO_PEERCRED socket option which does essentially what I'm proposing (obviously it doesn't use a `struct xucred`). Dima Dorfman dima@unixfreak.org > > > Robert N M Watson FreeBSD Core Team, TrustedBSD Project > robert@fledge.watson.org NAI Labs, Safeport Network Services > > On Wed, 27 Jun 2001, Dima Dorfman wrote: > > > Hi folks, > > > > Currently, there is no reliable way for a server listening on a Unix > > domain socket to find out the credentials of its peer until the peer > > sends something over the socket. Finding its credentials can be > > useful if the server only wants to accept connections from certain > > users. We already have SCM_CREDS, which will send the peer's > > credentials along with a message, but this is *not* sufficient as it > > may be unacceptable for the server to wait until the peer sends > > something; think of DoS attacked. Times don't help, either; think of > > SYN flood-like attacks. > > > > I would like to propose implementing such a facility as a socket > > option, LOCAL_PEERCRED. The payload would be am xucred structure with > > the effective credentials of the connect(2) caller. Granted these may > > not be the credentials of the process using the socket (think > > descriptor passing), but it doesn't matter; if a process hands a > > descriptor off to something else, it should be trusting it not to > > abuse it (this is a feature: think of opening a privileged port and > > dropping privileges). > > > > This has been discussed at least twice before, and nobody has a better > > idea. Again, I would like to stress the two requirements: (1) the > > accept(2) caller must be able to reliably obtain the effective > > credentials of the connect(2) caller, and (2) the accept(2) caller > > must be able to do (1) without relying on the connect(2) caller to > > send data (SCM_CREDS doesn't meet (2)). > > > > Patch attached. > > > > Comments? Suggestions? > > > > Thanks in advance, > > > > Dima Dorfman > > dima@unixfreak.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message