Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Message-ID: <005d01c23c7f$415d6c70$6132bc3e@BABEL>
From: "Conrad Scott" <Conrad DOT Scott AT dsl DOT pipex DOT com>
To: "egor duda" <cygwin-developers AT cygwin DOT com>
Cc: <cygwin-developers AT cygwin DOT com>
References: <20020804195150 DOT GA3381 AT redhat DOT com> <61668562061 DOT 20020805141450 AT logos-m DOT ru>
Subject: Re: 1.3.13?
Date: Mon, 5 Aug 2002 13:54:36 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000

"egor duda" <deo AT logos-m DOT ru> wrote:
> It turned out that original method to provide security via
creating
> event object with secret name doesn't really provide security :(
> I found several days ago that the namespace which contains
events,
> semaphores and other kernel objects can be listed by
non-privileged
> local user. That is, we can't, unfortunately, to rely on secrecy
of
> object name.

Thanks for the feedback Egor.  Perhaps some better news next time?
:-)  It was only a *small* assumption that processes would need to
be privileged to list the event names.  Boo, hiss.

> The obvious way to fix this with current approach is to
> add appropriate security information to handshake events so that
> non-privileged process won't be able to signal them. With
Conrad's
> approach, as far as i understand, handshake relies on mere
existence
> of needed object, so i don't know how to protect communications
in
> this case.

There's also the problem that you can't raise the security level
of the events since the two processes that are connecting can be
unrelated and so the only security level they might share would be
the wide-open one that everyone shares: i.e., no protection again.

The only other approach I know of at the moment is to use the
passing of secret cookies with WSAAccept and WSAConnect.  These
calls are only available in winsock2 but it's probably only a
small number of people with win 9x/ME who still have the original
winsock and they have no security anyway.

The basic idea would be to create two secret cookies and put them
in the UNIX domain socket file. The client would send one of them
as control data (or whatever it's called) when calling WSAConnect,
and the server would check that the cookie had been sent and then
return the other cookie in the control info to the client, which
would then check it likewise.

The existing patch is dead then, I assume (i.e. it's not a final
solution and no-one but me seems to have tripped over the existing
problem as yet).  I can do a patch based on the
WSAConnect/WSAAccept approach if people agree that it's a
reasonable approach.  Better suggestions always appreciated of
course.

There is some other stuff in the original patch I sent that I can
rip out and submit separately at some point (e.g. the
getpeername() fix for UNIX domain sockets).

// Conrad