Bus authentication on Windows v2.0

[Simon McVittie]

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