Google "twelve-factor app". Excerpt from a random article on medium.com:
"... most frameworks support the use of System Environment variables inside
configuration files. For instance, in the Spring Boot yaml file you can
write:
Security.oauth2.client.clientSecret: ${CL_SERVICE_PASSWORD}"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 On Tue, Nov 13, 2018 at 9:17 AM Lennart Poettering <lenn...@poettering.net> wrote: > On Di, 13.11.18 07:49, David Parsley (pars...@linuxjedi.org) 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: > > https://docs.docker.com/engine/swarm/secrets/#how-docker-manages-secrets > > 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 >
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
