<div dir="ltr">Google "twelve-factor app". Excerpt from a random article on <a href="http://medium.com">medium.com</a>:<div>"... most frameworks support the use of System Environment variables inside configuration files. For instance, in the Spring Boot yaml file you can write:</div><div>Security.oauth2.client.clientSecret: ${CL_SERVICE_PASSWORD}"</div>You're correct that's not a Unix security standard, and I couldn't find one - it's just a fairly common practice because environment variables are easy to use. Other systems engineers that I work with also rely on their environment being private from other users on large, multi-user research computing systems like the ones we manage. It's also a reasonable expectation that an unprivileged process can't trivially obtain the contents of a 0600:root:root file under /etc, or that a user-level exploit of an unrelated service could also trivially obtain that data.I'll just go ahead and concede that I'm wrong, and that GOPHER_SLACK_TOKEN and HUBOT_SLACK_TOKEN shouldn't be in an env var, and that my co-workers are also wrong to store a particular password in their environment. Regardless, that doesn't make it OK for systemd to hand out the contents of of that file or make service environment vars available to unprivileged users. You can think I'm a stubborn damned ignoramus if you like - but I'd be surprised if you think I'm the only damned ignoramus who thinks that environment data should be private to the process owner and root. I'm just one of the few who happened to notice the warning in the logs and investigated it.I think the real point here is the information disclosure vulnerability. I'm going to suggest to my team that we consider making /run/dbus/system_bus_socket 440 or 400 - no reason for these non-privileged users to have access to that, anyway.Thanks for giving this some thought.Regards,-David </div> <div class="gmail_quote"><div dir="ltr">On Tue, Nov 13, 2018 at 9:17 AM Lennart Poettering <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Di, 13.11.18 07:49, David Parsley (<a href="mailto:parsley@linuxjedi.org" target="_blank">parsley@linuxjedi.org</a>) wrote: > I disagree; privacy of environment variables to individual users on the > system is as fundamental as Unix file permissions. If a privileged process > (systemd) is configured to start a service and provide environment > variables to an unprivileged service account, it is a reasonable > expectation that said environment is only available to root and the service > account (and it's child processes), and not other arbitrary > users/processes. From a system security engineering perspective, it would > be better if systemd didn't start a service at all with 0600 on the unit > file, rather than violate the principle of Unix environment privacy, and in > fact should actually just check the world-read bit. Well, you are of course welcome to ignore whatever I say, but again, environment blocks are leaky, they propagate down the process tree, and are *not* generally understood as being secret. You appear dead set on using env vars for this. It's a very bad choice however, it's a pity you ignore comments that don't fit in your view of the world though. Note that even docker got this right, and their "docker secrets" feature, stores them in a file, not in an env var: <a href="https://docs.docker.com/engine/swarm/secrets/#how-docker-manages-secrets" rel="noreferrer" target="_blank">https://docs.docker.com/engine/swarm/secrets/#how-docker-manages-secrets</a> I mean, there's a lot to complain in what Docker does, but the way it looks, at least that they did get right... > Thanks aleivag; "systemctl show" was what I was looking for; unprivileged, > I was able to see the "Environment=" values, but not the contents of > /etc/gopherbot.env. I'm going to go ahead and update the Ansible role to > operate that way. Urks. I really don't hope this catches on. You are doing it wrong. Lennart -- Lennart Poettering, Red Hat </blockquote></div>