Date: Fri, 29 Jun 2001 20:51:27 -0700 From: Dima Dorfman <dima@unixfreak.org> To: "Jacques A. Vidrine" <n@nectar.com> Cc: arch@freebsd.org Subject: Re: Peer credentials on a Unix domain socket Message-ID: <20010630035127.1EAAD3E31@bazooka.unixfreak.org> In-Reply-To: <20010629064823.A61206@madman.nectar.com>; from n@nectar.com on "Fri, 29 Jun 2001 06:48:23 -0500"
next in thread | previous in thread | raw e-mail | index | archive | help
"Jacques A. Vidrine" <n@nectar.com> writes: > On Fri, Jun 29, 2001 at 12:48:46AM -0700, Dima Dorfman wrote: > > 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. > > There are two cases: either (1) anyone on the system can send mail, or > (2) only a subset of the users can send mail. > > In case (1), the Unix domain socket would be accessible by anyone. > > In case (2), add the subset of users to a common group, and make the > socket accessible only by that group. > > In either case, SCM_CREDS can be used to determine the client's > credentials. > > So I still don't quite get it. What attacks do you eliminate with the > scheme you suggest? Whether or not the credentials are available on > socket accept, or with the first message, the daemon still must wait > for a useful message from the client. Suppose Oscar wants to attack the mail system. If I use SCM_CREDS, Oscar can create umpteen connections and not send anything on them, and not only will I not know it's Oscar, but if I start refusing more connections he gets what he wants--he just successfully denied service to other users. If I can get the credentials at accept() time, I can set a flag the first time he connects that "Oscar connected"; then I can drop any following connections from Oscar knowing full well that Oscar is the only one being denied service. Everyone else is unaffected; thus, Oscar's attack is unsuccessful. Dima Dorfman dima@unixfreak.org 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?20010630035127.1EAAD3E31>