Security concerns on the Windows DBUS port

[Fan Wu]

Hi Ralf,

Thanks for pointing me to the link in the archive. The last response
from Christian in the thread is "All usefull examples are using
overlapped functions...". So what is wrong with using overlapped
functions (other than complexity)?

Regarding your question at the end of your last email, let me rephrase
my statement: named pipe can be used to transport data in W2k, XP and
Vista, but user credentials is easily available ONLY in Vista. For W2K
and XP it might be possible to retrieve peer's PID if the DBUS daemon
is privileged. I need to think about the details. BTW, pipes are not
available in Windows CE/Mobile platforms.

Cheers,
Fan


On 4/7/07, Ralf Habacker <ralf.habacker at freenet.de> wrote:
> Fan Wu schrieb:
> > Thanks for the response Ralf!
> >
> > I think the problem with windows named pipe is you can't do poll on
> > it. If so the problem can probably be solved by adding a wrapper
> > around WaitforMultipleObjects().
> This was already evaluated see
> http://lists.freedesktop.org/archives/dbus/2006-December/006631.html.
>
> > The auto-launch support is not enough to secure/authenticate the TCP
> > connection. The fundamental issue is you can't trust the information
> > "as told" by the peer. You can only trust the info as told by the OS,
> > like the credentials passed in Unix Domain socket. Or in WIndows Vista
> > (ONLY), the named pipe  server can obtain peer credentials thru calls
> > like GetNamedPipeClientProcessID().
> I understand from your answer that named pipe is only usable on Windows
> Vista. What kind of transport should be used to have a serious solution
> for Windows2000/XP ? Is it possible to emulate
> GetNamedPipeClientProcessID and similar required from
> http://msdn2.microsoft.com/en-us/library/aa365781.aspx with other
> functions ?
>
>
> Regards
> Ralf
>
> > On 4/7/07, Ralf Habacker <ralf.habacker at freenet.de> wrote:
> >> Fan Wu schrieb:
> >> > Hi all,
> >> >
> >> > I have couple of concerns on the Windows DBUS port. I've tried digging
> >> > into the archive but haven't found answers to my questions.
> >> >
> >> > I think the current windbus implementation using TCP socket is mainly
> >> > because it's hard to find a counterpart of Unix domain socket in
> >> > windows. But the problems with TCP socket are
> >> >
> >> > 1) possible conflict with personal firewall
> >> >
> >> > One of the projects I worked on used TCP socket of localhost for IPC,
> >> > and there are many cases that firewall has caused our products
> >> > useless. The percentage is small but the sheer number is large due to
> >> > the large installation base.
> >> There was a try to implement named pipes see
> >> http://webcvs.freedesktop.org/dbus/dbus/README.win?view=markup
> >>
> >> ".. there are some efforts to get named pipe running, but some
> >> design problems of the win32 api, we are not able to solve without
> >> bigger changes to the dbus code base let us stop this effort."
> >>
> >>
> >> > 2) how do you know the client is telling the truth about the user
> >> > credential (sid)?
> >> >
> >> > With Unix domain socket the OS is making sure the credentials passed
> >> > thru the socket is right (not faked). With TCP socket you are not
> >> > getting such help from the OS and you can't be sure the other end of
> >> > the transport is using libdbus to talk to you. So it's possible a
> >> > rogue application may use its own client side dbus implementation to
> >> > spoof a legitimate user.
> >> >
> >> > I'm not arguing DBUS shall fend against the case when the whole
> >> > machine has been 0wned, but I do expect the authentication in DBUS can
> >> > raise the bar higher.
> >> The recent windows implementation has a kind of autolaunch support by
> >> using a shared memory area, in which the dbus-daemon stores his
> >> connection informations. See
> >> http://webcvs.freedesktop.org/dbus/dbus/dbus/dbus-sysdeps-win.c?view=markup
> >>
> >> for more informations.
> >> There related functions are
> >>  _dbus_daemon_init(), _dbus_daemon_release(), which handles the shm area
> >> on the server side and
> >> _dbus_get_autolaunch_shm() which retrieves the related informations for
> >> the client side.
> >>
> >> I haven't written the implementation but this feature may be used to
> >> secure the tcp connection.
> >>
> >> Patches are welcome.
> >>
> >> Regards
> >> Ralf
> >>
> >>
>
>