Date: Wed, 27 Jun 2001 10:30:58 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Dima Dorfman <dima@unixfreak.org> Cc: arch@FreeBSD.ORG Subject: Re: Peer credentials on a Unix domain socket Message-ID: <3B3A1852.3C0027EC@mindspring.com> References: <20010627070628.AB5F13E2F@bazooka.unixfreak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Other than your uipc_ctloutput() function, which seems the wrong name, and the lack of generality in the function for future expansion (e.g. no "switch" statement), 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?3B3A1852.3C0027EC>