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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.