[systemd-devel] Environment-variable security?

[Tomasz Torcz]

On Wed, Nov 14, 2018 at 02:17:02AM +0100, Marek Howard wrote:
> Marek Howard píše v St 14. 11. 2018 v 01:35 +0100:
> > Lennart Poettering píše v Út 13. 11. 2018 v 15:17 +0100:
> > > On Di, 13.11.18 07:49, David Parsley (parsley at linuxjedi.org) wrote:
> > > 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.
> > 
> > It is not *that* common to pass secrets via environment variable but
> > it's nothing unusual, and many programs offer this interface. OpenVPN
> > comes to bind. Where such interface is offered, propagating down the
> > process tree is usually not a concern, because such programs usually
> > don't fork "untrusted" programs.
> > 
> > It's quite handy way to pass secrets and as I said above, there's
> > really no risk if it's done in cases where it makes sense. Of course
> > systemd leaking it to everyone makes it not usable with systemd, but
> > that's not really a problem with environment variables.
> 
> If you want some examples:
> 
> borgbackup - BORG_PASSPHRASE
> restic - RESTIC_PASSWORD
> openssl - env:var
> rsync - RSYNC_PASSWORD
> hub - GITHUB_PASSWORD, GITHUB_TOKEN
> rclone - RCLONE_CONFIG_PASS
> smbclient - PASSWD
> 
> Again, it's not so common, but it's not unusual and it's not insecure
> if you know what you're doing (which you usually are when you have
> powers to create system services).

  Generally, storing secret data in environment is common in
web microservices world, popularised by https://12factor.net/config
But those apps are supposed to be run by Kubernetes or other
container runtime - with dedicated clusters, PID namespaces and so on.
  Running them as plain unix (systemd) services is the wrong way
to run them ;)

-- 
Tomasz Torcz            There exists no separation between gods and men:
xmpp: zdzichubg at chrome.pl   one blends softly casual into the other.