Re: Hangs on connect to UNIX socket being listened on in the same process (was: Cygwin hanging in pselect)

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Jan 12 11:59, Erik Bray wrote:
> On Mon, Jan 9, 2017 at 6:16 PM, Corinna Vinschen wrote:
> > Right.  A better solution for the problem would be nice.  Ultimately
> > we want to check if the other side of the socket is actually a Cygwin
> > process which knows the secret, not a stray native Windows process
> > which accidentally hopped on the bandwagon, and we want to exchange
> > the credentials so a subsequent SO_PEERCRED call returns correct values.
> 
> Ah, okay. I found the original thread you mentioned, and I see that
> you sort of discussed some possibilities but nothing was quite
> satisfactory at the time, and it was dropped--you mentioned some idea
> about exchanging information via pipes, but that was a bit complicated
> and half-baked.
> 
> Christian described a scheme in that thread which at least seemed like
> a way out of the connect hanging problem, and also improved the
> security (I think) by having separate server and client secrets, so
> that a malicious server could not gain the socket secret from the
> client.  But he also worried:
> 
> > The only drawback which remains is that the client performs the send()
> > before first recv() unconditionally. It will realize the bad server secret
> > lately on first recv().
> 
> Though you wrote:
> 
> > Yeah, but it might be better than nothing and if it avoids the hangs,
> > even better.
> 
> Which is sort of how I feel, though I do appreciate the security
> implication.

I'm not sure there actually are security implications.  AF_LOCAL sockets
are local only, no network access.  And every Cygwin process knowing the
name of the socket file and having sufficient permisson to read the file
can connect.  And even a non-Cygwin process written by someone who knows
how Cygwin AF_LOCAL sockets work.  It's open source after all.

What this method mainly solves is to make reasonably sure that the peers
are actually Cygwin processes on both sides which know that this is an
AF_INET socket emulating an AF_LOCAL socket.  Plus SO_PEERCRED
emulation, but that's another problem just attached to the original
handshake.

Maybe we need to take a step back and just consider for a while what we
want:

Step 1:

  Make sure with whatever method that the process on the other side is
  actually a Cygwin process opening this socket as an AF_LOCAL socket.

Step 2:

  Exchange SO_PEERCRED information.

Step 3:

  If we did it really intelligent, maybe we finally also have a method
  to implement descriptor passing.  Finally.  After all these years.

And maybe, we should not actually use the socket itself to exchange
the information but rather create some kind of side-channle for that.

Especially in terms of step 3, I'm mulling over this for years now
and always something else got in the way and had to be done first.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: signature.asc
Description: PGP signature