Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Environment Variables Considered Harmful for Your Secrets

movingfast.io

Post reply on HN
Print view View original

41–50 of 120 posts

Re: Environment Variables Considered Harmful for Your Secrets

#41

Post by icebraining »

geocar wrote: post #27
hueving wrote: post #20

Earlier quoted context omitted.

>just start a server or an app with different env variables in the command line. Just reference a different config file on the command line. >You don't want your config or keys to depend on an OS,or a language. A path to a config file isn't an OS or language. The ini format is pretty widely supported. >Finally Env variables can be restricted to a set of users,so third party process started with a different one cant a…

BEGIN { $API = new Backend($ENV{credentials}); delete $ENV{credentials}; }; Filesystem permissions do not make it possible for a program to internally partition access to those credentials unless you (a) start it as root, or (b) delete the credentials file after reading it.

A user process can start subprocesses under different users, without access permissions to the files owned by parent. The most obvious way to do so is to use sudo.

Re: Environment Variables Considered Harmful for Your Secrets

#45

Post by tezza »

mreinsch wrote: post #32
tezza wrote: post #19

Isn't this what TPM was designed to avoid ? Neither files nor env variables. Most chipsets have a rather unused TPM function, and it should be possible to have developers and processes hook into that. Perhaps using tmptool ? On master process startup ask user for passphrase, and use that to query the TPM stored values ? http://manpages.courier-mta.org/htmlman1/tpmtool.1.html

I have to admit that I don't know a thing about TPM. Like is it also available in virtual environments like AWS is providing? How could this be automated? You don't want to enter a passphrase every time a server (re)boots. Would love to hear if anybody successfully used that.

  Cloud servers
  =============
Xen supports virtual TPM.

I'm no Amazon EC2 expert, but a quick google exposed a few keen souls who tried to use vTPM and failed. This would suggest that Amazon does not yet support vTPM.

  Re-entering passphrases
  ========================
Well, unless the machine is permissioned by default you will need to give a fresh instance new authorization. Permissioning by default is the same security problem you're trying to avoid though... just shifted. Your overall goal is to have the credentials inaccessible to sniffing, right ?

I guess you could set up some form of ssh-agent handshake to make the process less manual.

Re: Environment Variables Considered Harmful for Your Secrets

#46

Post by mreinsch »

tezza wrote: post #45
mreinsch wrote: post #32

Earlier quoted context omitted.

I have to admit that I don't know a thing about TPM. Like is it also available in virtual environments like AWS is providing? How could this be automated? You don't want to enter a passphrase every time a server (re)boots. Would love to hear if anybody successfully used that.

Cloud servers ============= Xen supports virtual TPM. I'm no Amazon EC2 expert, but a quick google exposed a few keen souls who tried to use vTPM and failed. This would suggest that Amazon does not yet support vTPM. Re-entering passphrases ======================== Well, unless the machine is permissioned by default you will need to give a fresh instance new authorization. Permissioning by default is the same security…

sniffing isn't the main issue I'm trying to avoid, it's accidental exposure. I.e. minimising the risk that during normal operations the secrets get exposed somehow.

Re: Environment Variables Considered Harmful for Your Secrets

#47

Post by mreinsch »

flavor8 wrote: post #43

I typically store the env _name_ in the environment, and then use that in my apps to build a path to the file containing secrets (e.g. /etc/{mycompany}/{environment}/myapp.conf). The file is locked down by ACLs or permissions.

as long as you don't store your config then in the same repository as your code, that works fine for me.

Re: Environment Variables Considered Harmful for Your Secrets

#48

Post by jmnicolas »

You could still store your secret keys in ENV but encrypt them. Only your program has the method to decrypt them so in the case of an ImageMagick sub process it would access only your encrypted secret key with no knowledge to decrypt it.

Same thing while debugging : only the encrypted key is printed.

Re: Environment Variables Considered Harmful for Your Secrets

#49

Post by riobard »

RubyPinch wrote: post #42

Assuming you arn't trying to go for top security, and just want a way to keep things safe from leaking due to errors and the such why not just make use of the OS's secrets store? for example, like how https://pypi.python.org/pypi/keyring operates

I would love to know more about this, but AFAIK OS secret stores are mostly a desktop-concept that requires a logged-in user (whose login password is used to decrypt the secret store). On a deployment server, you don't have those.

Re: Environment Variables Considered Harmful for Your Secrets

#50

Post by kiallmacinnes »

ntucker wrote: post #22

My company has an internal bit of infrastructure that I think is a somewhat novel approach that allows us to never have any secrets stored unencrypted on disk. There's a server (a set of servers, actually, for redundancy) called the secret server, and its only job is to run a daemon that owns all the secrets. When an app on another server is started up, it must be done from a shell (we use cap) which has an SSH agent…

This reminds me of OpenStack Barbican (Previously called CloudKeep.. kinda..) initially built by Rackspace. A good intro video at [1].

One of the interesting (and optional) things is does, is provide a agent to run on your instances that require the secrets, the agent implements a FUSE filesystem, and access to this filesytem is controlled by policy. For example - A policy can say "Allow exactly 1 read of /secrets/AWS.json within 120 seconds of boot". Any out of policy access attempts can cause the instance to be blacklisted, preventing any future secret access etc..

[1]: https://www.openstack.org/summit/portland-2013/session-video...

Post reply on HN