Security concerns on the Windows DBUS port

[Ralf Habacker]

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
>>
>>