mirror of
https://gitlab.gnome.org/GNOME/glib.git
synced 2026-10-24 00:49:00 +03:00
efac370744
When running setuid, ignore this auth mechanism and hence also the `$G_DBUS_COOKIE_SHA1_KEYRING_DIR` environment variable. This was considered as part of #2168 but determined at the time to not be a problem. It’s since been reported as a vulnerability. I don’t see how it can realistically be exploited in practice: - This D-Bus auth mechanism is strongly discouraged and iirc it’s only kept around for use on Windows - The setuid binary would have to be running as a D-Bus server in a peer-to-peer configuration, which is very rare - Even rarer to run it as setuid root, rather than as a system service via a service manager - And the configuration would have to force this auth mechanism to be used instead of any more appropriate mechanism That said, I don’t see any reason why we _shouldn’t_ ignore this environment variable when setuid. ¯\_(ツ)_/¯ The fallback for `$G_DBUS_COOKIE_SHA1_KEYRING_DIR` is to build the keyring path using `$HOME`, but that is equally as susceptible to attacker modification when running setuid, hence we disable the whole auth mechanism. This brings GIO inline with what libdbus does. Spotted by cavid. Thanks to the Sovereign Tech Resilience programme from the Sovereign Tech Agency. ID: #YWH-PGM9867-164 Signed-off-by: Philip Withnall <pwithnall@gnome.org>
