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.
Regards,
-David
On Tue, Nov 13, 2018 at 5:18 AM Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote:
On Mo, 12.11.18 17:41, aleivag (aleivag@xxxxxxxxx) wrote:
> You can define those secrets on /etc/robotsecret.txt, and then on your unit
> you do `EnvironmentFile=/etc/robotsecret.txt`
>
> then you protect /etc/robotsecret.txt as you would normally do
Don't do this. This is only partially secure, and that only by
coincidence, not by design. env vars are generally not considered
secrets, and will still propagate down the tree.
If you have secrets pick a place where they are strictly access
controlled, and where this access control is built into the concept
itself. Files on disk work (with their age old UNIX access mode) and
kernel keyrings work too (they have been designed just for this
purpose). env vars do not qualify. Neither in understanding of its
users, not in actual code.
Lennart
--
Lennart Poettering, Red Hat
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
