From owner-freebsd-arch Fri Jun 29 0:48:50 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 F21D037B40B for ; Fri, 29 Jun 2001 00:48:46 -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 884873E2F; Fri, 29 Jun 2001 00:48:46 -0700 (PDT) To: "Jacques A. Vidrine" Cc: arch@freebsd.org Subject: Re: Peer credentials on a Unix domain socket In-Reply-To: <20010628105609.K30889@madman.nectar.com>; from n@nectar.com on "Thu, 28 Jun 2001 10:56:09 -0500" Date: Fri, 29 Jun 2001 00:48:46 -0700 From: Dima Dorfman Message-Id: <20010629074846.884873E2F@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 "Jacques A. Vidrine" writes: > On Wed, Jun 27, 2001 at 12:06:28AM -0700, 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. > > > > 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? > > What possible actions could the server take upon determining the > credentials of the client? Either drop the connection or go forward. > > Why not just create the domain socket with permissions such that only > authorized clients can connect to them in the first place? I suspect > you'd answer that it isn't fine-grained enough, to which I would > probably suggest that maybe the application can stand a wee bit more > design work :-) or that ACLs could make it fine-grained enough. > > Or maybe I've missed something entirely. Suppose I want to rewrite sendmail(8) so that it doesn't have to be setuid root to put outgoing mail on the queue (right now, /usr/sbin/sendmail [1] needs to be setuid to root to write to the queue; allowing anybody to write to the queue opens up other problems [2]). I intend to do this by having a privileged daemon listen on a Unix domain socket and receieve and queue mail for local users. In order to do this, I need to reliably figure out who the user submitting the message is. This can be done right now with SCM_CREDS, but since I wouldn't be able to figure out who the user is *until* they send something over the socket I open myself up to various attacks as I described in my original e-mail. Dima Dorfman dima@unixfreak.org [1] I know about mailwrapper; I chose to ignore it in this example for simplicity. [2] It may be possble to work around some of these, but it's imperfect. P.S. I don't actually plan to do what I described above. I just want to make it possible for somebody else to do it :-). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message