From owner-freebsd-arch Wed Jun 27 12:51:58 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 77E6737B401 for ; Wed, 27 Jun 2001 12:51:53 -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 3A00F3E32; Wed, 27 Jun 2001 12:51:37 -0700 (PDT) To: tlambert2@mindspring.com Cc: arch@FreeBSD.ORG Subject: Re: Peer credentials on a Unix domain socket In-Reply-To: <3B3A1852.3C0027EC@mindspring.com>; from tlambert2@mindspring.com on "Wed, 27 Jun 2001 10:30:58 -0700" Date: Wed, 27 Jun 2001 12:51:37 -0700 From: Dima Dorfman Message-Id: <20010627195137.3A00F3E32@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 Terry Lambert writes: > Dima Dorfman wrote: > > 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. > > It would be useful if this were more general than you are > making it. > > In particular, it would be useful to provide the ability > to have a daemon that would sit on a FIFO, and then when > people make requests to "connect" (or "bind" or even > "socket"), to administratively deny the request and have > their system call return EADMIN. > > The request would be sent up the FIFO only if there were > a listenener, and would, of course, be capable of timing > out. > > This is the same local credentials check you appear to want > to do, but it must be extended, since there would be an > in kernel proxy acting as a "man in the middle". > > > Consider a dialup gateway, which wants to permit some > traffic to bring the link up, but wants to stop other > traffic before it becomes "demand". This can't be done > by port, since you may wish to permit one application > or user ID to bring the link up as a result of a DNS > requests, but not another (e.g. sendmail vs. IRC vs. > HTTP). > > This also means that I would need to be able to set a > "demand source" as part of my credential, not just use > the credentials raw. It sounds like what you're describing is a 'fifofw' (FIFO firewall; as compared to 'ipfw'). This may be something worth investigating, but it doesn't replace the need for a simple, reliable way to find out who the connect(2) caller is. > Other than your uipc_ctloutput() function, which seems > the wrong name, What's wrong with the name? It fills in the pr_ctloutput field in a struct protosw; I think uipc_ctloutput is quite appropriate. > and the lack of generality in the function > for future expansion (e.g. no "switch" statement), Fair enough. I'll fix that. Thanks, Dima Dorfman dima@unixfreak.org > this > looks like a good start on something that could be more > generally useful. > > -- Terry > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message