Date: Fri, 4 May 2001 21:47:02 -0400 From: "William E. Baxter" <web@superscript.com> To: hackers@freebsd.org Subject: Re: Getting peer credentials on a unix domain socket Message-ID: <20010504214702.A29392@zeus.superscript.com> In-Reply-To: <20010504170738.U18676@fw.wintelcom.net>; from bright@wintelcom.net on Fri, May 04, 2001 at 05:07:38PM -0700 References: <20010504230540.00BEE3E0B@bazooka.unixfreak.org> <20010504170738.U18676@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 04, 2001 at 05:07:38PM -0700, Alfred Perlstein wrote: > * Dima Dorfman <dima@unixfreak.org> [010504 16:06] wrote: > > Is there a reliable method of obtaining the credentials (uid/gid) of a > > peer (SOCK_STREAM sockets only, obviously) on a unix domain socket? > > All the Stevens books I have suggest that there isn't, but I'm > > wondering if something has been developed since those books were > > published. Note that a BSD/OS-like LOCAL_CREDS socket opt is not > > sufficient because using the latter the process must wait until the > > peer sends something before they can learn its credentials. If this > > process intends to drop the connection if it's not from an authorized > > source, this may lead to a DoS attack. Timers don't help, either; > > think of TCP SYN flood-like attacks. > > Someone had some patches for a getpeercreds() syscall, but I wasn't > happy with it considering we already have the sendmsg() stuff to pass > credentials along with the fact that the initial creator of a socket > may be long gone before it's used to connect to something. I wrote that patch. Links to my patches appear at http://www.superscript.com/patches/intro.html Explanatory material and links to the same appear at http://www.superscript.com/ucspi-ipc/getpeereid.html My patch is designed to satisfy these conditions: 1. Server can obtain credentials of connect() caller (effective uid and gid suffice). 2. Server can obtain credentials without depending on client to send data. Having met these conditions, it is nearly trivial to create privileged servers that run behind a unix socket, in an environment under their own control. In many instances one can replace setuid programs with such servers. How does one meet these two conditions with vanilla FreeBSD, NetBSD, or OpenBSD? So far as I know, the answer is "One cannot." Unfortunately, sendmsg() mechanisms fail to satisfy condition (2). As Dima pointed out, this means a local user can launch DoS attacks anonymously. The server operates at the mercy of the client. And as Alfred points out, perhaps unintentionally, the information should be passed at connect(), because the client process may exit before accept() returns. Many simple servers require credentials and nothing more. In such cases, there is no reason for the client to wait until accept() returns. My ucspi-ipc package provides a framework for turning filters into servers based on getpeereid(): http://www.superscript.com/ucspi-ipc/intro.html A collection of simple servers, some of which perform operations normally delegated to setuid programs, is available at: http://www.superscript.com/ipctools/intro.html Linux already has sufficient basis for implementing getpeereid(), with getsockopt() and SO_PEERCRED, and my ucspi-ipc package uses them to satisfy the two conditions stated above. I created patches for NetBSD, FreeBSD, and OpenBSD, hoping to contribute better facilities to these projects. None of the implementors displayed any enthusiasm. Nor did they demonstrate how to satisfy the two conditions stated above with existing system features. Too bad. If you think that getpeereid(), or sufficient basis for it, should appear in future versions of *BSD, please tell the implementors. My implementation remains theirs for the asking. W. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010504214702.A29392>