Date: Wed, 27 Jun 2001 12:51:37 -0700 From: Dima Dorfman <dima@unixfreak.org> To: tlambert2@mindspring.com Cc: arch@FreeBSD.ORG Subject: Re: Peer credentials on a Unix domain socket Message-ID: <20010627195137.3A00F3E32@bazooka.unixfreak.org> In-Reply-To: <3B3A1852.3C0027EC@mindspring.com>; from tlambert2@mindspring.com on "Wed, 27 Jun 2001 10:30:58 -0700"
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert <tlambert2@mindspring.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010627195137.3A00F3E32>