Thank you again for the informative reply. I saw two dbus-daemons running on my Ubuntu server; I killed the user d-bus daemon process running as me and nothing seems to break, so while it’s there, it doesn’t seem to be used by anything on my server.
While I do note that systemd man page, it goes in to no detail about how dbus leaks the environment.
Looking at the D-Bus specification [1], org.freedesktop.DBus.UpdateActivationEnvironment is the only thing which concerns itself about the environment. It says that the “session bus activated services inherit the environment of the bus daemon”, so it looks like the D-Bus leakage is any system-level environmental variables set when the D-Bus daemons are started, or any variables set using UpdateActivationEnvironment.
The concern here appears to be that system-level environmental variables aren’t safe. I don’t see anything about a user process setting something like export FOO="top secret password" being more unsafe than a chmod 700 or chmod 600 file.
I have already noted the various ways environmental variables can leak on this page:
> I saw two dbus-daemons running on my Ubuntu server; I killed the user d-bus daemon process running as me and nothing seems to break, so while it’s there, it doesn’t seem to be used by anything on my server.
Every systemd service is exposed on a dbus path in systemd. You can query a service's environment like so:
$ systemctl status foo
● foo.service - Can we read this service's environment over dbus?
Loaded: loaded (/etc/systemd/system/foo.service; static)
Active: active (running) since Tue 2021-12-14 23:00:10 PST; 6min ago
Main PID: 104167 (sleep)
Tasks: 1 (limit: 9366)
CPU: 1ms
CGroup: /system.slice/foo.service
└─104167 sleep 3600
$ qdbus --system org.freedesktop.systemd1 /org/freedesktop/systemd1/unit/foo_2eservice org.freedesktop.systemd1.Service.Environment
Error: org.freedesktop.DBus.Error.AccessDenied
Rejected send message, 2 matched rules; type="method_call", sender=":1.761" (uid=1000 pid=104282 comm="/usr/lib/qt5/bin/qdbus --system org.freedesktop.sy") interface="org.freedesktop.systemd1.Service" member="Environment" error name="(unset)" requested_reply="0" destination="org.freedesktop.systemd1" (uid=0 pid=1 comm="/sbin/init splash ")
$ sudo qdbus --system org.freedesktop.systemd1 /org/freedesktop/systemd1/unit/foo_2eservice org.freedesktop.systemd1.Service.Environment
FOO=secret-secret
So you can read it but it seems systemd does enforce some sane default permissions on who can read the environment.
While I do note that systemd man page, it goes in to no detail about how dbus leaks the environment.
Looking at the D-Bus specification [1], org.freedesktop.DBus.UpdateActivationEnvironment is the only thing which concerns itself about the environment. It says that the “session bus activated services inherit the environment of the bus daemon”, so it looks like the D-Bus leakage is any system-level environmental variables set when the D-Bus daemons are started, or any variables set using UpdateActivationEnvironment.
The concern here appears to be that system-level environmental variables aren’t safe. I don’t see anything about a user process setting something like export FOO="top secret password" being more unsafe than a chmod 700 or chmod 600 file.
I have already noted the various ways environmental variables can leak on this page:
https://github.com/samboy/rg32hash/blob/master/C/microrg32.m...
I will update the D-Bus information there based on what I read in the D-Bus spec.
[1] https://dbus.freedesktop.org/doc/dbus-specification.html