Bug#994961: glib2.0: gnome-keyring unable to unlock login keyring on some systems since GLib 2.70.0-1

[Francois Marier]

Source: glib2.0
Version: 2.70.0-1
Severity: important

It looks like Bug #981420 was reintroduced in 2.70.0-1, as foreshadowed by
the 2.66.4-4 changelog entries:

glib2.0 (2.66.4-4) unstable; urgency=medium
.
* d/patches: Update patch series to upstream commit 2.66.4-27-g0051c0635
- Partially revert security hardening from 2.66.4-2: allow
DBUS_SESSION_BUS_ADDRESS to be taken from the environment by
setcap executables (to avoid regressing gnome-keyring) and by
setgid executables (to avoid regressing msmtp).
(Closes: #981420, #981555)
Note that this is likely to be reverted in GLib 2.70.x to provide
better hardening. The D-Bus session bus is not designed to be used
by processes that have elevated privileges.

I am no longer able to start gnome-keyring-daemon:

$ gnome-keyring-daemon -r
** Message: 14:57:35.890: couldn't connect to dbus session bus: Cannot spawn a message bus when setuid
** Message: 14:57:35.890: Replacing daemon, using directory: /run/user/1000/keyring
GNOME_KEYRING_CONTROL=/run/user/1000/keyring
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh

gnome-keyring-daemon itself isn't SETUID:

$ ls -l /usr/bin/gnome-keyring-daemon
-rwxr-xr-x 1 root root 1.1M Aug 21 04:43 /usr/bin/gnome-keyring-daemon*

$ sudo getcap /usr/bin/gnome-keyring-daemon
/usr/bin/gnome-keyring-daemon cap_ipc_lock=ep

I do have the dbus-user-session package installed.

Francois

-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.utf8, LC_CTYPE=fr_CA.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

[Simon McVittie]

Control: reassign 994961 src:glib2.0,gnome-keyring
Control: found 994961 glib2.0/2.70.0-1
Control: found 994961 gnome-keyring/3.36.0-1
Control: tags 994961 + bookworm sid
Control: forwarded 994961 https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/77

Post by Francois Marier
It looks like Bug #981420 was reintroduced in 2.70.0-1, as foreshadowed by
the 2.66.4-4 changelog entries

Yes, the deadline set by the upstream GLib maintainers was reached and
the security hardening has been reinstated.

To work with this version, the gnome-keyring package needs to stop
making gnome-keyring-daemon setcap (which I thought it already had,
but apparently not...)

User processes are allowed to lock a reasonable amount of memory by
default, which makes CAP_IPC_LOCK a lot less necessary than it used to be.
On typical Debian systems, they are allowed to lock an *unreasonable*
amount of memory by default due to unintended interactions between PAM
and systemd, which is a denial-of-service risk for systems with lots of
users (#976373) but works in our favour here.

Post by Francois Marier
$ gnome-keyring-daemon -r
** Message: 14:57:35.890: couldn't connect to dbus session bus: Cannot spawn a message bus when setuid
** Message: 14:57:35.890: Replacing daemon, using directory: /run/user/1000/keyring
GNOME_KEYRING_CONTROL=/run/user/1000/keyring
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh

...

Post by Francois Marier
I do have the dbus-user-session package installed.

I'm surprised by this. It's clearly still picking up XDG_RUNTIME_DIR
from the environment, so I would have expected it to be able to connect
to $XDG_RUNTIME_DIR/bus (arguably that's a bug, in that it should not be
trusting the environment at all when run with capabilities, but it's
necessary as long as gnome-keyring-daemon is setcap).

Do you have a socket at $XDG_RUNTIME_DIR/bus owned by your uid?

What is the status of the session bus? (`systemctl --user status dbus.service`
and `systemctl --user status dbus.socket`)

"Cannot spawn a message bus when setuid" is shorthand, and not 100%
accurate: it really means "when setuid, setgid, setcap, after an AppArmor
transition involving modes U, P or C, or with any other elevated privilege"
but that seems too long for an error message.

smcv

[Francois Marier]

Post by Simon McVittie

Post by Francois Marier
I do have the dbus-user-session package installed.

I'm surprised by this. It's clearly still picking up XDG_RUNTIME_DIR
from the environment, so I would have expected it to be able to connect
to $XDG_RUNTIME_DIR/bus (arguably that's a bug, in that it should not be
trusting the environment at all when run with capabilities, but it's
necessary as long as gnome-keyring-daemon is setcap).
Do you have a socket at $XDG_RUNTIME_DIR/bus owned by your uid?

It doesn't look like it:

$ ls -lh $XDG_RUNTIME_DIR/bus
ls: cannot access '/run/user/1000/bus': No such file or directory

Post by Simon McVittie
What is the status of the session bus? (`systemctl --user status dbus.service`
and `systemctl --user status dbus.socket`)

$ systemctl --user status dbus.service
Failed to get properties: Process org.freedesktop.systemd1 exited with status 1
$ systemctl --user status dbus.socket
Failed to get properties: Process org.freedesktop.systemd1 exited with status 1

I'll give gnome-keyring 40.0-3 a go once it makes it to unstable.

Francois

[Simon McVittie]

Post by Francois Marier
$ ls -lh $XDG_RUNTIME_DIR/bus
ls: cannot access '/run/user/1000/bus': No such file or directory

Looks like you have a non-functional installation of dbus-user-session
(which would put you in the same situation as people without that package
installed), but that should probably be a separate bug report against
dbus-user-session rather than being in-scope for this one.

smcv