Today I learned that unprivileged users can run "systemctl show servicename" to see all the environment variables set in the .service file.
This means if someone sets their AWS_SECRET_ACCESS_KEY in there (or any other secret), it can be read by an attacker even if they don't have read privileges to read the .service file.
For defenders, use EnvironmentFile= instead of Environment= and as long as your environment file has the correct privileges, you will be fine on this front.
@breizh Nope, anyone can use journalctl, it's just certain commands that require higher privs. For example, "status" works just fine as a regular user. It seems that if one is just looking around and not restarting/reloading things, a normal user is sufficient.
@breizh Oh wait, you said journalctl, not systemctl. Yeah, as far as I know journalctl requires root access (or possibly some other level of non-standard priv).
@adam
systemd and its consequences have been a disaster for the human race
I guess in some corporations it might be used that way, but most often you either own the thing, or it implements a service offered to you so you only interact with it via APIs.
@taylan I've seen some places where administrators are not allowed to be root under any circumstances (and that was technically enforced, not just a company rule), but I agree that it's rare.
In either case, it could allow an unprivileged internet attacker who gained remote code execution to elevate from an untrusted user (apache, www-data, etc.)
Come to think of it, looking at service info might be a good thing to alert on. Seems like an uncommon command
I didn't specifically mention it before, but the assumption here is that the attacker can run commands on your server as an unprivileged user. So they did something like exploit this: https://freeradical.zone/@thenewoil/108053163388824610
The impact is that they may then be able to elevate privileges or pivot to other parts of the infrastructure using any secrets they find.