Bus authentication on Windows v2.0

[Simon McVittie]

On 06/06/16 20:31, LRN wrote:
> DBUS_WINDOWS_SSPI_* would work as well (there's no length limit on
> mechanism name, is there? also, should it always be all all-caps?)

I don't know. The SASL RFC (RFC 4422 I think) would tell you. All-caps
does seem to be conventional - EXTERNAL, DIGEST and ANONYMOUS are among
the standard mechanisms.

If you are inventing a D-Bus-specific SASL mechanism (and not, for
instance, writing a standards-track RFC for SSPI SASL mechanisms in
general) then it would make sense for it to be somewhat consistent with
the only other D-Bus-specific SASL mechanism, which is DBUS_COOKIE_SHA1.

> I haven't seen any provisions for PID in SSPI. I can imagine why - MS is
> not too big on processes, but is big on threads. For example, many services
> run within the same svchost.exe process, in different threads. In such
> environment proving your PID does not carry any meaning. It might be more
> meaningful to look at "Session ID" and "Integrity Level" (which say less
> about "who" runs the client, and more about "where" the client is running).

If you can include the Session ID and/or Integrity Level in the D-Bus
credentials, that would also be potentially useful information.

On Unix platforms, we can currently tell callers the user ID, process
ID, Linux LSM context (for AppArmor, SELinux, etc.), and Solaris ADT
audit session data (but I don't know what that is or means and so far
nobody has told me) - in practice we never have all of those, but we can
have a subset. On Windows, we can tell callers the SID and sometimes the
process ID. Look for GetConnectionCredentials in the specification for
details of most of these.

Any new pieces of authentication/credential data that you want to add
should be made available in GetConnectionCredentials().

> Security context handle is useful for further SSPI API calls (to
> [en|de]crypt and sign/verify), but for authentication purposes it can do
> only three things, AFAICS

Perhaps you'd just use the security context handle or the access token
to get the SID and then throw it away, then. I don't know.

>> In GDBus, you'd probably put it in a GCredentials object.
> 
> Right now i'm leaning towards declaring GCredentials to be "*NIX only" API.
> It (or maybe just the code that uses it) focuses too much on carrying
> credentials as ancillary data for a nul byte sent over *NIX domain socket,
> and verified by the kernel.

This is how it is done 90% of the time, but GCredentials does seem to be
intended to represent the broader concept of an OS-native identity:
you'll notice that GDBusAuthObserver only provides a GCredentials object
to the authorize-authenticated-peer signal, so anything you want to use
to describe the user's identity has to fit in the GCredentials.

(Contrast with the equivalent in libdbus, which has a separate
dbus_connection_set_unix_user_function() and
dbus_connection_set_windows_user_function(), and does not make any
attempt to have an OS-agnostic API for arbitrary credentials.)

If in doubt, talk to the GIO maintainers about how they see
GCredentials' role. If they see it as a lower-level concept like struct
ucred, then GDBusAuthObserver might need to grow an equivalent of
authorize-authenticated-peer that is higher-level, perhaps using an
object more analogous to PolkitIdentity.

> Plugging SSPI-based GCredentials negotiation (if i were to implement that)
> into existing glib-based application (which by itself won't go without code
> modifications, as GCredentials are currently sent over GUnixConnection
> explicitly) will just violate the protocol (it does violate D-Bus protocol,
> AFAIU).

You can't send the underlying OS credentials accompanying byte 0 for use
with EXTERNAL auth if they aren't the expected ancillary message, but it
would be reasonable to represent the result of DBUS_COOKIE_SHA1 as
(pseudocode) GCredentials(uid=getuid(), pid=unspecified), and similarly
it would be reasonable to represent the result of SSPI as a structure
containing all the credentials we know and nothing else.

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>