2013-09-18 19:40:09 +02:00
|
|
|
/* GIO - GLib Input, Output and Streaming Library
|
|
|
|
|
*
|
|
|
|
|
* Copyright 2013 Red Hat, Inc.
|
|
|
|
|
*
|
2022-05-18 10:12:45 +02:00
|
|
|
* SPDX-License-Identifier: LGPL-2.1-or-later
|
|
|
|
|
*
|
2013-09-18 19:40:09 +02:00
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
|
* License as published by the Free Software Foundation; either
|
2017-05-27 18:21:30 +02:00
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
2013-09-18 19:40:09 +02:00
|
|
|
*
|
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU Lesser General
|
2014-01-23 12:58:29 +01:00
|
|
|
* Public License along with this library; if not, see <http://www.gnu.org/licenses/>.
|
2013-09-18 19:40:09 +02:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef __G_CREDENTIALS_PRIVATE_H__
|
|
|
|
|
#define __G_CREDENTIALS_PRIVATE_H__
|
|
|
|
|
|
|
|
|
|
#include "gio/gcredentials.h"
|
|
|
|
|
#include "gio/gnetworking.h"
|
|
|
|
|
|
2019-10-14 09:22:24 +02:00
|
|
|
/*
|
|
|
|
|
* G_CREDENTIALS_SUPPORTED:
|
|
|
|
|
*
|
|
|
|
|
* Defined to 1 if GCredentials works.
|
|
|
|
|
*/
|
|
|
|
|
#undef G_CREDENTIALS_SUPPORTED
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* G_CREDENTIALS_USE_LINUX_UCRED, etc.:
|
|
|
|
|
*
|
|
|
|
|
* Defined to 1 if GCredentials uses Linux `struct ucred`, etc.
|
|
|
|
|
*/
|
|
|
|
|
#undef G_CREDENTIALS_USE_LINUX_UCRED
|
|
|
|
|
#undef G_CREDENTIALS_USE_FREEBSD_CMSGCRED
|
|
|
|
|
#undef G_CREDENTIALS_USE_NETBSD_UNPCBID
|
|
|
|
|
#undef G_CREDENTIALS_USE_OPENBSD_SOCKPEERCRED
|
|
|
|
|
#undef G_CREDENTIALS_USE_SOLARIS_UCRED
|
2018-02-18 15:26:54 +01:00
|
|
|
#undef G_CREDENTIALS_USE_APPLE_XUCRED
|
2022-01-19 17:35:45 +01:00
|
|
|
#undef G_CREDENTIALS_USE_WIN32_PID
|
2019-10-14 09:22:24 +02:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* G_CREDENTIALS_NATIVE_TYPE:
|
|
|
|
|
*
|
|
|
|
|
* Defined to one of G_CREDENTIALS_TYPE_LINUX_UCRED, etc.
|
|
|
|
|
*/
|
|
|
|
|
#undef G_CREDENTIALS_NATIVE_TYPE
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* G_CREDENTIALS_NATIVE_SIZE:
|
|
|
|
|
*
|
|
|
|
|
* Defined to the size of the %G_CREDENTIALS_NATIVE_TYPE
|
|
|
|
|
*/
|
|
|
|
|
#undef G_CREDENTIALS_NATIVE_SIZE
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* G_CREDENTIALS_UNIX_CREDENTIALS_MESSAGE_SUPPORTED:
|
|
|
|
|
*
|
|
|
|
|
* Defined to 1 if we have a message-passing API in which credentials
|
|
|
|
|
* are attached to a particular message, such as `SCM_CREDENTIALS` on Linux
|
|
|
|
|
* or `SCM_CREDS` on FreeBSD.
|
|
|
|
|
*/
|
|
|
|
|
#undef G_CREDENTIALS_UNIX_CREDENTIALS_MESSAGE_SUPPORTED
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* G_CREDENTIALS_SOCKET_GET_CREDENTIALS_SUPPORTED:
|
|
|
|
|
*
|
|
|
|
|
* Defined to 1 if we have a `getsockopt()`-style API in which one end of
|
|
|
|
|
* a socket connection can directly query the credentials of the process
|
|
|
|
|
* that initiated the other end, such as `getsockopt SO_PEERCRED` on Linux
|
|
|
|
|
* or `getpeereid()` on multiple operating systems.
|
|
|
|
|
*/
|
|
|
|
|
#undef G_CREDENTIALS_SOCKET_GET_CREDENTIALS_SUPPORTED
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* G_CREDENTIALS_SPOOFING_SUPPORTED:
|
|
|
|
|
*
|
|
|
|
|
* Defined to 1 if privileged processes can spoof their credentials when
|
|
|
|
|
* using the message-passing API.
|
|
|
|
|
*/
|
|
|
|
|
#undef G_CREDENTIALS_SPOOFING_SUPPORTED
|
|
|
|
|
|
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-14 09:47:39 +02:00
|
|
|
/*
|
|
|
|
|
* G_CREDENTIALS_PREFER_MESSAGE_PASSING:
|
|
|
|
|
*
|
|
|
|
|
* Defined to 1 if the data structure transferred by the message-passing
|
|
|
|
|
* API is strictly more informative than the one transferred by the
|
|
|
|
|
* `getsockopt()`-style API, and hence should be preferred, even for
|
|
|
|
|
* protocols like D-Bus that are defined in terms of the credentials of
|
|
|
|
|
* the (process that opened the) socket, as opposed to the credentials
|
|
|
|
|
* of an individual message.
|
|
|
|
|
*/
|
|
|
|
|
#undef G_CREDENTIALS_PREFER_MESSAGE_PASSING
|
|
|
|
|
|
2020-03-15 19:10:53 +01:00
|
|
|
/*
|
|
|
|
|
* G_CREDENTIALS_HAS_PID:
|
|
|
|
|
*
|
|
|
|
|
* Defined to 1 if the %G_CREDENTIALS_NATIVE_TYPE contains the process ID.
|
|
|
|
|
*/
|
|
|
|
|
#undef G_CREDENTIALS_HAS_PID
|
|
|
|
|
|
2013-09-18 19:40:09 +02:00
|
|
|
#ifdef __linux__
|
|
|
|
|
#define G_CREDENTIALS_SUPPORTED 1
|
|
|
|
|
#define G_CREDENTIALS_USE_LINUX_UCRED 1
|
|
|
|
|
#define G_CREDENTIALS_NATIVE_TYPE G_CREDENTIALS_TYPE_LINUX_UCRED
|
|
|
|
|
#define G_CREDENTIALS_NATIVE_SIZE (sizeof (struct ucred))
|
|
|
|
|
#define G_CREDENTIALS_UNIX_CREDENTIALS_MESSAGE_SUPPORTED 1
|
|
|
|
|
#define G_CREDENTIALS_SOCKET_GET_CREDENTIALS_SUPPORTED 1
|
2013-09-19 22:09:38 +02:00
|
|
|
#define G_CREDENTIALS_SPOOFING_SUPPORTED 1
|
2020-03-15 19:10:53 +01:00
|
|
|
#define G_CREDENTIALS_HAS_PID 1
|
2013-09-18 19:40:09 +02:00
|
|
|
|
2015-01-27 13:38:31 +01:00
|
|
|
#elif defined(__FreeBSD__) || \
|
|
|
|
|
defined(__FreeBSD_kernel__) /* Debian GNU/kFreeBSD */ || \
|
|
|
|
|
defined(__GNU__) /* GNU Hurd */ || \
|
|
|
|
|
defined(__DragonFly__) /* DragonFly BSD */
|
2013-09-18 19:40:09 +02:00
|
|
|
#define G_CREDENTIALS_SUPPORTED 1
|
|
|
|
|
#define G_CREDENTIALS_USE_FREEBSD_CMSGCRED 1
|
|
|
|
|
#define G_CREDENTIALS_NATIVE_TYPE G_CREDENTIALS_TYPE_FREEBSD_CMSGCRED
|
|
|
|
|
#define G_CREDENTIALS_NATIVE_SIZE (sizeof (struct cmsgcred))
|
|
|
|
|
#define G_CREDENTIALS_UNIX_CREDENTIALS_MESSAGE_SUPPORTED 1
|
2013-09-19 22:09:38 +02:00
|
|
|
#define G_CREDENTIALS_SPOOFING_SUPPORTED 1
|
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-14 09:47:39 +02:00
|
|
|
/* GLib doesn't implement it yet, but FreeBSD's getsockopt()-style API
|
|
|
|
|
* is getpeereid(), which is not as informative as struct cmsgcred -
|
|
|
|
|
* it does not tell us the PID. As a result, libdbus prefers to use
|
|
|
|
|
* SCM_CREDS, and if we implement getpeereid() in future, we should
|
|
|
|
|
* do the same. */
|
|
|
|
|
#define G_CREDENTIALS_PREFER_MESSAGE_PASSING 1
|
2020-03-15 19:10:53 +01:00
|
|
|
#define G_CREDENTIALS_HAS_PID 1
|
2013-09-18 19:40:09 +02:00
|
|
|
|
2014-04-15 16:09:22 +02:00
|
|
|
#elif defined(__NetBSD__)
|
|
|
|
|
#define G_CREDENTIALS_SUPPORTED 1
|
|
|
|
|
#define G_CREDENTIALS_USE_NETBSD_UNPCBID 1
|
|
|
|
|
#define G_CREDENTIALS_NATIVE_TYPE G_CREDENTIALS_TYPE_NETBSD_UNPCBID
|
|
|
|
|
#define G_CREDENTIALS_NATIVE_SIZE (sizeof (struct unpcbid))
|
2014-09-01 18:42:43 +02:00
|
|
|
/* #undef G_CREDENTIALS_UNIX_CREDENTIALS_MESSAGE_SUPPORTED */
|
2014-04-15 16:09:22 +02:00
|
|
|
#define G_CREDENTIALS_SPOOFING_SUPPORTED 1
|
2020-03-15 19:10:53 +01:00
|
|
|
#define G_CREDENTIALS_HAS_PID 1
|
2014-04-15 16:09:22 +02:00
|
|
|
|
2013-09-18 19:40:09 +02:00
|
|
|
#elif defined(__OpenBSD__)
|
|
|
|
|
#define G_CREDENTIALS_SUPPORTED 1
|
|
|
|
|
#define G_CREDENTIALS_USE_OPENBSD_SOCKPEERCRED 1
|
|
|
|
|
#define G_CREDENTIALS_NATIVE_TYPE G_CREDENTIALS_TYPE_OPENBSD_SOCKPEERCRED
|
|
|
|
|
#define G_CREDENTIALS_NATIVE_SIZE (sizeof (struct sockpeercred))
|
|
|
|
|
#define G_CREDENTIALS_SOCKET_GET_CREDENTIALS_SUPPORTED 1
|
2013-09-19 22:09:38 +02:00
|
|
|
#define G_CREDENTIALS_SPOOFING_SUPPORTED 1
|
2020-03-15 19:10:53 +01:00
|
|
|
#define G_CREDENTIALS_HAS_PID 1
|
2013-09-19 22:09:38 +02:00
|
|
|
|
|
|
|
|
#elif defined(__sun__) || defined(__illumos__) || defined (__OpenSolaris_kernel__)
|
|
|
|
|
#include <ucred.h>
|
|
|
|
|
#define G_CREDENTIALS_SUPPORTED 1
|
|
|
|
|
#define G_CREDENTIALS_USE_SOLARIS_UCRED 1
|
|
|
|
|
#define G_CREDENTIALS_NATIVE_TYPE G_CREDENTIALS_TYPE_SOLARIS_UCRED
|
|
|
|
|
#define G_CREDENTIALS_NATIVE_SIZE (ucred_size ())
|
|
|
|
|
#define G_CREDENTIALS_UNIX_CREDENTIALS_MESSAGE_SUPPORTED 1
|
|
|
|
|
#define G_CREDENTIALS_SOCKET_GET_CREDENTIALS_SUPPORTED 1
|
2020-03-15 19:10:53 +01:00
|
|
|
#define G_CREDENTIALS_HAS_PID 1
|
2013-09-18 19:40:09 +02:00
|
|
|
|
2022-11-02 11:01:09 +01:00
|
|
|
#elif defined(__APPLE__)
|
2018-02-18 15:26:54 +01:00
|
|
|
#include <sys/ucred.h>
|
|
|
|
|
#define G_CREDENTIALS_SUPPORTED 1
|
|
|
|
|
#define G_CREDENTIALS_USE_APPLE_XUCRED 1
|
|
|
|
|
#define G_CREDENTIALS_NATIVE_TYPE G_CREDENTIALS_TYPE_APPLE_XUCRED
|
|
|
|
|
#define G_CREDENTIALS_NATIVE_SIZE (sizeof (struct xucred))
|
|
|
|
|
#undef G_CREDENTIALS_UNIX_CREDENTIALS_MESSAGE_SUPPORTED
|
|
|
|
|
#define G_CREDENTIALS_SOCKET_GET_CREDENTIALS_SUPPORTED 1
|
|
|
|
|
#define G_CREDENTIALS_SPOOFING_SUPPORTED 1
|
|
|
|
|
#define G_CREDENTIALS_HAS_PID 0
|
|
|
|
|
|
2021-11-24 11:15:05 +01:00
|
|
|
void _g_credentials_set_local_peerid (GCredentials *credentials,
|
|
|
|
|
pid_t pid);
|
|
|
|
|
|
2022-01-19 17:35:45 +01:00
|
|
|
#elif defined(_WIN32)
|
|
|
|
|
#define G_CREDENTIALS_SUPPORTED 1
|
|
|
|
|
#define G_CREDENTIALS_USE_WIN32_PID 1
|
|
|
|
|
#define G_CREDENTIALS_NATIVE_TYPE G_CREDENTIALS_TYPE_WIN32_PID
|
|
|
|
|
#define G_CREDENTIALS_NATIVE_SIZE (sizeof (DWORD))
|
|
|
|
|
#define G_CREDENTIALS_SOCKET_GET_CREDENTIALS_SUPPORTED 1
|
|
|
|
|
#define G_CREDENTIALS_HAS_PID 1
|
|
|
|
|
|
2022-11-02 11:01:09 +01:00
|
|
|
#endif
|
2013-09-18 19:40:09 +02:00
|
|
|
|
|
|
|
|
#endif /* __G_CREDENTIALS_PRIVATE_H__ */
|
