Re: Bus authentication on Windows v2.0
Simon McVittie <simon.mcvittie-ZGY8ohtN/[email protected]>
| Newsgroups | gmane.comp.freedesktop.dbus |
|---|---|
| Organization | Collabora Ltd. |
| Message-ID | <[email protected]> |
On 03/06/16 20:30, LRN wrote: > I've looked through the dbus-1.9.14 code Please prefer to base all work on new D-Bus features on current git master (currently 1.11.x), or if you absolutely must use an older version, the newest stable branch (currently 1.10.x). > and it seems that it goes like this: > 1) Client sends its SID > 2) Server checks that Client connects from localhost and grabs its source port > 3) Server looks up TCP tables for a local process that bound a socket to > that port and gets its process ID > 4) Server looks up SID of the user under which the process by that process > ID runs > 5) Server checks the SID-from-process against the SID sent by the client. > > Is that correct? Yes. We are not 100% sure that this is actually entirely secure: it might be subject to race conditions. Please read <https://bugs.freedesktop.org/show_bug.cgi?id=83499> before proceeding. I would love to be able to replace this with something provably secure, but I don't work on Windows or know the finer points of its APIs, so someone who knows Windows well would have to lead this. > I think i can make SSPI-based authentication work. However, i'm unsure how > to frame the data exchange between two processes. > If implemented with no explicit leaning toward D-bus, it would have to > exchange auth data in-band (in place of the single NUL byte, which on *nix > is accompanied by ancillary auth data; Windows does not allow ancillary > data for streaming TCP sockets). The D-Bus authentication handshake uses SASL (RFC 4422). On Unix, we normally use the trivial EXTERNAL mechanism in conjunction with ancillary auth data. On Windows, I think we normally use a non-standard SASL mechanism, DBUS_COOKIE_SHA1, which is based on home directory ownership: I think it's about the client proving that it can read a "magic cookie" from a file written by the server, but I might be misremembering. If there is already a SASL mechanism for SSPI, please use it. If not, you're welcome to invent a DBUS_SSPI SASL mechanism with whatever in-band data exchange you need. -- Simon McVittie Collabora Ltd. <http://www.collabora.com/> _______________________________________________ dbus mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dbus