Bug 68741

Created attachment 84893 [details] [review]
Add sid attribute to policies

Compiling dbus with windows service support is currently only supported by the cmake build system.

In the current state the autolaunch protocol do not work when dbus-daemon is running as windows service because it runs under a different user http://msdn.microsoft.com/en-us/library/windows/desktop/ms684190%28v=vs.85%29.aspx. 

Instead it is required to use a localhost tcp connection with a dedicated port. 
For the dbus-daemon this is done at configure time with -DDBUS_SYSTEM_BUS_DEFAULT_ADDRESS=tcp:host=localhost,port=xxx

and for the clients at runtime with 

set DBUS_SYSTEM_BUS_ADDRESS=tcp:host=localhost,port=xxx
dbus-monitor --system 

for example.

(In reply to comment #0)
> The append patches implements a basic implementation for running dbus as
> windows service, which has been requested.

Which use-cases need a system dbus-daemon, and why? My understanding had been that the sort of things that use the system bus on Unix should use native Windows facilities on Windows (for instance, instead of talking to NetworkManager/ConnMan/wicd you ask the Windows API about your Internet connection). Windows is rather more homogenous than Unix.

We shouldn't support a system bus on Windows unless we can get it to a sufficiently high-quality state that it is secure, both in terms of "users cannot impersonate other users" and "users cannot crash the dbus-daemon or make it execute arbitrary code".

At the moment, I'm not at all confident that D-Bus on Windows meets those criteria. For instance, see Bug #35311; and notice that _dbus_check_dir_is_private_to_user(), _dbus_windows_user_is_process_owner() are both stubs, despite being security-sensitive.

(In reply to Simon McVittie from comment #3)

>_dbus_windows_user_is_process_owner() are both stubs, 

Attachment 84893 [details] contains a related unreviewed patch.

(In reply to Ralf Habacker from comment #4)
> (In reply to Simon McVittie from comment #3)
> 
> >_dbus_windows_user_is_process_owner() are both stubs, 
> 
> Attachment 84893 [details] contains a related unreviewed patch.

OK, that patch does make _dbus_windows_user_is_process_owner() not be a stub.

I still have the same concerns about this, though:

* do we need it? On Linux, and secondarily on other Unix, the system bus is a standard API for talking to pieces of OS infrastructure like NetworkManager, ConnMan, systemd and so on. On Windows, the OS infrastructure (as provided by Microsoft) is probably never going to accessible via D-Bus.

* is the implementation quality of dbus-on-Windows at a level where it is ready for multi-user use? (Bug #35311 suggests that the answer to that is no.)

* in particular, are the functions that determine the identity of connecting processes safe to use in the presence of malicious users? Bug #83499 documents why what we do is OK for AF_UNIX, but it isn't clear to me that the same is true for TCP sockets on Windows.

As long as dbus-daemon on Windows only runs on a per-user basis, we can say that it isn't safe to be a security boundary and leave it at that; but IMO it would be irresponsible to provide a bus that is intended for use by multiple users, without also ensuring that it is actually suitable for that use.

(In reply to Simon McVittie from comment #5)
> (In reply to Ralf Habacker from comment #4)
> > (In reply to Simon McVittie from comment #3)
> > 
> > >_dbus_windows_user_is_process_owner() are both stubs, 
> > 
> > Attachment 84893 [details] contains a related unreviewed patch.
> 
> OK, that patch does make _dbus_windows_user_is_process_owner() not be a stub.
> 
> I still have the same concerns about this, though:
> 
> * do we need it? On Linux, and secondarily on other Unix, the system bus is
> a standard API for talking to pieces of OS infrastructure like
> NetworkManager, ConnMan, systemd and so on. On Windows, the OS
> infrastructure (as provided by Microsoft) is probably never going to
> accessible via D-Bus.
https://en.wikipedia.org/wiki/D-Bus stated that the system bus provides access services (i.e. services provided by the operating system and also by any system daemons)."

For the latter we have a hen/egg deadlock: Because there is no system bus nobody will create dbus based system daemons and because there are no system daemons for system bus, it is argumented there is no need for it. 

Think about network manager system service for example: It is used on linux by KDE, gnome and probably other desktop environment apps through dbus system bus. Providing similar applications on Windows requires to implemented access to network management for every single application again, while adding a system service, which provides org.freedesktop.NetworkManager through dbus system bus needs to be implemented only once.

The "Solid" framework for example provides access to hardware for KDE4/KF5 applications. There is an implementation using dbus system bus for linux and a separate Windows implementation using native api. Gnome and other desktop apps requiring similar service needs to implement the same stuff again and again. I guess that there are more similar examples.

> * is the implementation quality of dbus-on-Windows at a level where it is
> ready for multi-user use? (Bug #35311 suggests that the answer to that is
> no.)
> 
> * in particular, are the functions that determine the identity of connecting
> processes safe to use in the presence of mrealicious users? Bug #83499
> documents why what we do is OK for AF_UNIX, but it isn't clear to me that
> the same is true for TCP sockets on Windows.
> 
> As long as dbus-daemon on Windows only runs on a per-user basis, we can say
> that it isn't safe to be a security boundary and leave it at that; but IMO
> it would be irresponsible to provide a bus that is intended for use by
> multiple users, without also ensuring that it is actually suitable for that
> use.
Agreed, we need to list all open issues and make a plan how to implement them. 

May be there is a chance to get a GsoC or similar program student to get dedicated development resources.

(In reply to Ralf Habacker from comment #6)
> For the latter we have a hen/egg deadlock: Because there is no system bus
> nobody will create dbus based system daemons and because there are no system
> daemons for system bus, it is argumented there is no need for it. 

Windows already has system services, though! They're part of the Windows platform, and they're provided by the OS vendor, namely Microsoft.

On community-driven open source platforms like the various Linux and *BSD distributions, dbus and D-Bus services are convenient because they're part of the operating system, and they're part of the operating system because the OS vendor (Red Hat, Debian, FreeBSD etc.) has decided they're sufficiently useful to be worth the space and maintenance effort they consume. One of the factors influencing dbus' inclusion in open source platforms is that it's what the free desktop environments like GNOME and KDE want to use, and the free desktop environments are responsible for some major features of open source platforms, so their authors have significant influence over what OS vendors will do.

On proprietary platforms like Windows and macOS, the freedesktop.org stack is niche at best - GNOME and KDE just don't have much influence over what Microsoft and Apple do and don't include in their OSs. They are vanishingly unlikely to include dbus, however convenient we might make it for them; and when projects like KDE are ported to Windows, it's all about adapting KDE to make it fit on an immovable Windows platform, not about improving the Windows platform to make it support KDE better (because we can't).

> The "Solid" framework for example provides access to hardware for KDE4/KF5
> applications. There is an implementation using dbus system bus for linux and
> a separate Windows implementation using native api.

Sure, and that's fine. On "the Linux platform" (so far as such a thing exists), the way you deal with disks is to talk to udisks2 (or udev, or the kernel directly), so that's what Solid does. On the Windows platform, the way you deal with disks is to talk to some Microsoft component, so that's what Solid does. Isn't that the purpose of having abstraction layers like Solid?

Yes, I recognise that it isn't ideal that when Solid and gvfs both want to provide an abstraction for disk devices, they both have to have a udisks2 backend for Linux and a Windows backend for Windows. However, if they used a Windows port of udisks2 on Windows (moving the abstraction layer into udisks2), then anyone wanting to install an app that made use of Solid (perhaps as a non-administrator) would have to install the Windows port of udisks2 (as an administrator), which is rather inconvenient, because Windows isn't very good at representing software as packages with interdependencies.

(I suspect the udisks2 D-Bus API might also not be the right "shape" for representing Windows devices, because that wasn't in its design scope.)

Similar considerations apply to system services other than udisks2 (and I know Solid covers a lot more services than just udisks2), it was just a convenient example.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/89.