Date: Wed, 27 Jun 2001 12:54:01 -0700 From: Dima Dorfman <dima@unixfreak.org> To: Robert Watson <rwatson@freebsd.org> Cc: arch@freebsd.org Subject: Re: Peer credentials on a Unix domain socket Message-ID: <20010627195401.D392C3E31@bazooka.unixfreak.org> In-Reply-To: <Pine.NEB.3.96L.1010627150012.16165D-100000@fledge.watson.org>; from rwatson@freebsd.org on "Wed, 27 Jun 2001 15:19:52 -0400 (EDT)"
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson <rwatson@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010627195401.D392C3E31>