Security concerns on the Windows DBUS port

Tue Apr 10 03:01:42 PDT 2007

MANSION, James, GBM schrieb:
> I'm sorry I can't post to the list from here, and I'll probably not get
> around to it from home, but you can as you imply implement something similar
> to poll *for input* using Windows overlapped IO mechanism.  While you might
> end up using WaitFor... Its not strictly necessary in all cases - I believe
> you can just issue a zero-byte overlapped read and in the callback you can
> set an associated 'readable' flag and perform a wakeup on the thread that is
> blocking in your fake poll.
>
> If you google around for Windows techniques for handling 10s of thousands of
> connections you should find info on this, because its necessary to avoid
> busting per-process limits on the number of pages that can be locked into
> memory as async IO targets.
>
> James
>   
Thanks for this info, I have send this to the dbus list too for the record.
Ralf

>
> -----Original Message-----
> From: dbus-bounces at lists.freedesktop.org
> [mailto:dbus-bounces at lists.freedesktop.org] On Behalf Of Fan Wu
> Sent: 07 April 2007 18:30
> To: Ralf Habacker
> Cc: dbus at lists.freedesktop.org
> Subject: Re: Security concerns on the Windows DBUS port
>
> 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().
>
> 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().
>
> With TCP socket (XP and Vista only) you can call GetExtendedTcpTable() to
> enumerate opened TCP sockets and find their PIDs. But again I don't think
> using TCP for transport is a serious solution or a solution of "industrial
> strength".
>
> Cheers,
> Fan
>
> 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=m
>> arkup
>> 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
>>
>>
>>     
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
>
> ***********************************************************************************
> The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. 
> Authorised and regulated by the Financial Services Authority 
>  
> This e-mail message is confidential and for use by the 
> addressee only. If the message is received by anyone other 
> than the addressee, please return the message to the sender 
> by replying to it and then delete the message from your 
> computer. Internet e-mails are not necessarily secure. The 
> Royal Bank of Scotland plc does not accept responsibility for 
> changes made to this message after it was sent. 
>
> Whilst all reasonable care has been taken to avoid the 
> transmission of viruses, it is the responsibility of the recipient to 
> ensure that the onward transmission, opening or use of this 
> message and any attachments will not adversely affect its 
> systems or data. No responsibility is accepted by The 
> Royal Bank of Scotland plc in this regard and the recipient should carry 
> out such virus and other checks as it considers appropriate. 
> Visit our websites at: 
> www.rbs.com
> www.rbsgc.com
> www.rbsmarkets.com
> ***********************************************************************************
>