Commit Graph

11 Commits

Author SHA1 Message Date
Simon McVittie
ee502dbbe8 GDBus: prefer getsockopt()-style credentials-passing APIs
Conceptually, a D-Bus server is really trying to determine the credentials
of (the process that initiated) a connection, not the credentials that
the process had when it sent a particular message. Ideally, it does
this with a getsockopt()-style API that queries the credentials of the
connection's initiator without requiring any particular cooperation from
that process, avoiding a class of possible failures.

The leading '\0' in the D-Bus protocol is primarily a workaround
for platforms where the message-based credentials-passing API is
strictly better than the getsockopt()-style API (for example, on
FreeBSD, SCM_CREDS includes a process ID but getpeereid() does not),
or where the getsockopt()-style API does not exist at all. As a result
libdbus, the reference implementation of D-Bus, does not implement
Linux SCM_CREDENTIALS at all - it has no reason to do so, because the
SO_PEERCRED socket option is equally informative.

This change makes GDBusServer on Linux more closely match the behaviour
of libdbus.

In particular, GNOME/glib#1831 indicates that when a libdbus client
connects to a GDBus server, recvmsg() sometimes yields a SCM_CREDENTIALS
message with cmsg_data={pid=0, uid=65534, gid=65534}. I think this is
most likely a race condition in the early steps to connect:

        client           server
    connect
                         accept
    send '\0' <- race -> set SO_PASSCRED = 1
                         receive '\0'

If the server wins the race:

        client           server
    connect
                         accept
                         set SO_PASSCRED = 1
    send '\0'
                         receive '\0'

then everything is fine. However, if the client wins the race:

        client           server
    connect
                         accept
    send '\0'
                         set SO_PASSCRED = 1
                         receive '\0'

then the kernel does not record credentials for the message containing
'\0' (because SO_PASSCRED was 0 at the time). However, by the time the
server receives the message, the kernel knows that credentials are
desired. I would have expected the kernel to omit the credentials header
in this case, but it seems that instead, it synthesizes a credentials
structure with a dummy process ID 0, a dummy uid derived from
/proc/sys/kernel/overflowuid and a dummy gid derived from
/proc/sys/kernel/overflowgid.

In an unconfigured GDBusServer, hitting this race condition results in
falling back to DBUS_COOKIE_SHA1 authentication, which in practice usually
succeeds in authenticating the peer's uid. However, we encourage AF_UNIX
servers on Unix platforms to allow only EXTERNAL authentication as a
security-hardening measure, because DBUS_COOKIE_SHA1 relies on a series
of assumptions including a cryptographically strong PRNG and a shared
home directory with no write access by others, which are not necessarily
true for all operating systems and users. EXTERNAL authentication will
fail if the server cannot determine the client's credentials.

In particular, this caused a regression when CVE-2019-14822 was fixed
in ibus, which appears to be resolved by this commit. Qt clients
(which use libdbus) intermittently fail to connect to an ibus server
(which uses GDBusServer), because ibus no longer allows DBUS_COOKIE_SHA1
authentication or non-matching uids.

Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: https://gitlab.gnome.org/GNOME/glib/issues/1831
2019-10-28 19:56:00 +00:00
Simon McVittie
ef1035d9d8 gcredentialsprivate: Document the various private macros
Signed-off-by: Simon McVittie <smcv@collabora.com>
2019-10-28 19:54:08 +00:00
Sébastien Wilmet
3bf4a720c3 gio/: LGPLv2+ -> LGPLv2.1+
Sub-directories inside gio/ already processed in a previous commit:
- fam/
- gdbus-2.0/ (which contains only codegen/)
- gvdb/
- inotify/
- tests/
- win32/
- xdgmime/

Other sub-directories inside gio/:
- completion/: no license headers
- kqueue/: not LGPL, BSD-style license

https://bugzilla.gnome.org/show_bug.cgi?id=776504
2017-05-29 19:53:34 +02:00
Dan Winship
e8d3f29300 gcredentialsprivate: clarify the USE_FREEBSD_CMSGCRED users
Add comments clarifying what the three non-FreeBSD platforms using
G_CREDENTIALS_USE_FREEBSD_CMSGCRED are.
2015-01-27 07:38:31 -05:00
Peeter Must
4c54b9fe31 gcredentials: Add support for DragonFly
https://bugzilla.gnome.org/show_bug.cgi?id=743508
2015-01-27 07:31:24 -05:00
Patrick Welche
e763d93456 GCredentials: credentials messages are not correctly supported on NetBSD
https://bugzilla.gnome.org/show_bug.cgi?id=735819
2014-09-04 08:26:27 -04:00
Patrick Welche
afce39c228 gcredentials: add NetBSD support
https://bugzilla.gnome.org/show_bug.cgi?id=728256
2014-06-28 14:06:36 -04:00
Daniel Mustieles
078dbda148 Updated FSF's address 2014-01-31 14:31:55 +01:00
Dan Winship
5a269e5a90 gcredentials: add Solaris support
Based on patches from Igor Pashev.

https://bugzilla.gnome.org/show_bug.cgi?id=705029
2013-10-04 09:51:31 -04:00
Dan Winship
66edac7fb9 gcredentials: add Hurd support
It uses the same system as FreeBSD.

https://bugzilla.gnome.org/show_bug.cgi?id=708265
2013-10-04 09:51:31 -04:00
Dan Winship
cedd697bf8 gcredentials: add internal macros to simplify all the #ifdefs
Rather than having lots of obscure platform-based #ifdefs all over
gio, define some macros in gcredentialsprivate.h, and use those to
simplify the rest of the code.

https://bugzilla.gnome.org/show_bug.cgi?id=701482
2013-10-04 09:51:31 -04:00