Re: 1.3.13?

["Conrad Scott" <Conrad dot Scott at dsl dot pipex dot com>]

"egor duda" <deo@logos-m.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