4

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?

2

Do not use environment vars because of the scripts your webserver is hosting can be vulnerable AND you can't controll them all(scripts). Any script compromised - and it's no problem to dump the whole environment. My suggestion is to use a ControlPort with authentication and telnet-like protocol for on-flight configuration of a newly-spawned instance. Spawn-and-config, providing a key in runtime config. And take a look at LDAP, by the way - it's a proper storage for certificates IMHO

  • Thanks @Alexey. You have a good point. For now I will just suggest people to run the web server and the scripts with different users.... you wanted to do that anyway if the server was able to access a private key in a file. – dsign Jan 2 '16 at 7:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.