Details: snoop environment variables using D-Bus IPC

Question

The page at: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Environment says:

Environment variables set for a unit are exposed to unprivileged clients via D-Bus IPC [...]

I don't have much experience with stuff as low-level as buses, so I'd hugely appreciate someone providing more details (or even a PoC) on this. Specific questions:

1. Does this apply to environment variables passed via systemd only, or any process' environment variables?
2. Is this attack possible with standard server access, as any other non-privileged user? Does one need to compile an 'exploit' into a binary, or can existing system binaries be used for this? (I found only C examples, nothing e.g. in Bash.)
3. If it really is possible for any non-privileged process to read any other's env vars, how is this not a bigger deal? Why then are env vars considered the 'secure option' in most any context?

Answer 1

D-Bus doesn't leak the environment variables of a process. Rather, what happens is that systemd broadcasts the configuration of a service that it starts, including the Environment=… settings.

You don't need any special privileges on a normal system (for example on Ubuntu 20.04 out of the box). You can watch things happening for yourself with dbus-monitor --system, or query the current state with e.g. systemctl show SERVICENAME. Hardened systems may block access; this would typically be the same kind of system that comes with complex SELinux (or equivalent) rules and, for example, blocks users from even listing other users' processes.

It's not a big deal because system services are typically configured through world-readable files anyway. Monitoring D-Bus tells you when the service is started, but if you want to know how it's configured, just read the configuration file.

More generally (maybe it's mentioned elsewhere in the systemd documentation?), making a systemd unit file private won't really buy you any confidentiality. Don't put secret stuff in there. Put secret stuff in files that are separate from the general configuration.

As the manual mention, another reason not to pass secrets in the environment to system services is that the environment is propagated to subprocesses. It's hard to be sure that a deaemon won't call some auxiliary program which might be configured to run in a debug mode that dumps its environment somewhere. Environment variables of a process don't leak directly to other users, but they can leak indirectly from the actions of the process or a subprocess. So environment variables are a good way to pass secrets to “leaf” commands such as gpg, but not to complex services.