Bus authentication on Windows v2.0

LRN <[email protected]> Fri, 3 Jun 2016 22:30:04 +0300
Newsgroups	gmane.comp.freedesktop.dbus
Message-ID	<[email protected]>
I've been working on improving glib Windows port, currently i'm looking for
a good way to implement GCredentials - which is a glib thing that is mostly
used for D-Bus authentication.

I've looked through the dbus-1.9.14 code to see how authentication done,
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?

I've been looking at other ways to authenticate processes, and it seems
that SSPI (with "Negotiate" SSP, which means NTLM or Kerberos) might be a
more "correct" way of doing this. SSPI does not require any privileges,
SSPI is actually intended for authentication/identification, and SSPI is
backed by the OS as such.

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).
If implemented at higher level, in [g]D-bus code, it will work with AUTH
protocol itself (server is still free to infer SID of the other process
from processID/port, but the SID that is received as a result of a
successful SSPI exchange will override that).

Does that make any sense?

-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org

_______________________________________________
dbus mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dbus
signature.asc (application/pgp-signature, 473 B)