I'm working on a webserver that stores resources in Redis. To make swarm-deployments as hassle-free as possible, I'm implementing an option where the server doesn't need to access the filesystem to fetch operational data.
The Redis communication protocol is clear-text. That is OK because most assets are not sensitive, and the user is not expected to make the Redis swarm accessible from the Internet. Except for TLS certificate private keys, which also need to be stored in the Redis database. If an attacker gains access to any of the stations in the private subnet with access to the Redis swarm, she wouldn't need anything else to connect to Redis and fetch said key.
So my first idea for a solution was to encrypt the TLS certificate key before storing it. But then I need to provide each process in my swarm with the symmetric encryption key. Now, apparently, it is not safe to provide that symmetric encryption key via command line parameters. For example, if I do:
$ cat /proc/6630/status
...
Uid: 0 0 0 0
...
and then
$ cat /proc/6630/cmdline
/sbin/dhclient-d-sf/usr/lib/NetworkManager/nm-dhcp-client.action-pf/run/sendsigs.omit.d/network-manager.dhclient-eth0.pid-lf/var/lib/NetworkManager/dhclient-90380716-3851-4c0f-98c5-aaf16acdc395-eth0.lease-cf/var/lib/NetworkManager/dhclient-eth0.confeth0
from a regular account, I see that a user with minimum privileges is perfectly able to snoop command-line parameters of processes started by any other user, e.g., root. So, using a command-line parameter is still not good enough.
So I have option 2: to store the private key in a protected location in the filesystem. This one choice defeats my intention of having the server to not access the filesystem. And option 3, to store part of the symmetric encryption key in the web server binary itself and give people a way to personalize the key fragment. At least in theory, with option 3 an attacker would need to be logged in a station running the web server, and have enough privileges to read the binary of the web server itself. This is equivalent to the status quo situation today where the private key is stored in a protected file in the server.
Option 4 is to put the symmetric key in an environment variable, apparently that's safer:
$ cat /proc/6630/environ
cat: /proc/6630/environ: Permission denied
Is there a way to avoid leaks of the key through /proc/<PID>/cmdline in scenario 1? In scenario 4, is there a way in which the environment of a process can leak that I didn't account for? And finally, is there any other obvious design choice that I didn't take into account?
