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

31–40 of 120 posts

Re: Environment Variables Considered Harmful for Your Secrets

#31

Post by geocar »

greenleafjacob wrote: post #26

I wrote a library to handle mixed configuration values by using asymmetric RSA encryption [1]. [1]: https://github.com/jacobgreenleaf/greybox

There are lots of problems with this, not the least of which being:

• Configuration files can be trivially forged (rsa without signing)

• Many configuration files can be trivially decrypted without the key (rsa use on potentially big files)

• Keys can be trivially recovered in multiple ways (global variable, ptrace)

Users might be tricked into using your library despite the fact it offers them no real security except false security.

I recommend placing a warning that it is not intended to be used by anyone at any time.

Re: Environment Variables Considered Harmful for Your Secrets

#32

Post by mreinsch »

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.

Re: Environment Variables Considered Harmful for Your Secrets

#33

Post by perlgeek »

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…

The system sounds very well thought-out, though probably not applicable at my $work location.

> When an app on another server is started up, it must be done from a shell

That's a no-go for many setups. It doesn't integrate well with how Linux distros usually start services (systemd, upstart, sysv init, ...), and means you have to have another way to manage dependencies between your services.

> When an app on another server is started up, it must be done from a shell (we use cap) which has an SSH agent forwarded to it. In order for the app to get its database passwords and various other secrets, it makes a request to the secret server (over a TLS-encrypted socket), which checks your SSH identity against an ACL

At this point you could have used ssh right away, no? Any reason you used TLS + checking SSH agent instead?

Re: Environment Variables Considered Harmful for Your Secrets

#34

Post by justincormack »

mreinsch wrote: post #18
CraigJPerry wrote: post #15

This article is misguided. Environment variables can be more secure than files. Furthermore, in the presented case there's no improvement in security by switching to a file. To address my second claim first: file permissions work at the user or group level. ACLs / MAC likewise. SELinux can be configured to assist in this case but it's not as trivial as it appears at first glance, it would be easier to use environment…

Thanks. I'm mainly looking at this from the point of how your secrets could be accidentally exposed. I applaud to postfix for sanitising the ENV, and it's very good practice to do so. But are all the frameworks doing it correctly? Maybe some code is then also just spawning new processes without sanitising? You could argue that's a bug then (which I completely agree), but not all projects are run like postfix...

The basic system call, execve, requires that you specify the environment explicitly. The whole idea of an inherited environment is a construct of shells and historic libc functions, and the libc functions that do not have an explicit environment should be deprecated. The man page examples show constructing the environment from scratch, which is best practise: you should never refer to the whole environment, just access individual items from it, ie never reference environ, just getenv etc.

Re: Environment Variables Considered Harmful for Your Secrets

#35

Post by jmillikin »

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 sounds like a pretty standard bastion server configuration. The use of SSH is novel, usually I see the bastion address provided as a command-line option and a TLS certificate used to authenticate the client.

Re: Environment Variables Considered Harmful for Your Secrets

#36

Post by jmillikin »

perlgeek wrote: post #33
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…

The system sounds very well thought-out, though probably not applicable at my $work location. > When an app on another server is started up, it must be done from a shell That's a no-go for many setups. It doesn't integrate well with how Linux distros usually start services (systemd, upstart, sysv init, ...), and means you have to have another way to manage dependencies between your services. > When an app on another…

  > That's a no-go for many setups. It doesn't integrate well
  > with how Linux distros usually start services (systemd,
  > upstart, sysv init, ...)
Change the daemon config file to use a small wrapper script, which initializes the SSH environment and then execs the target binary. Assuming a reasonable setup, this should be trivial.

  > At this point you could have used ssh right away, no?
  > Any reason you used TLS + checking SSH agent instead?
It sounds like they take an SSH identity certificate from the agent, send it via TLS, and then the remote process verifies it. This would have fewer potential security issues than trying to lock down a user's SSH login shell.

Re: Environment Variables Considered Harmful for Your Secrets

#37

Post by TeMPOraL »

hueving wrote: post #20
aikah wrote: post #10

Earlier quoted context omitted.

> filesystem permissions are reasonably flexible Env makes things really flexible.For instance,you can call a program with env variables directly thus overriding the default ones,which simplify configuring applications. You dont have to have a test set-up,a production-setup or a staging set-up,just start a server or an app with different env variables in the command line. You don't want your config or keys to depend…

>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…

>> 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.

Either of that seems to be able to be read straight from argv[0] of the process, so don't forget about cleaning that up.

Re: Environment Variables Considered Harmful for Your Secrets

#38

Post by jheriko »

bodyfour wrote: post #11

Classic UNIX behavior was that environment variables were public (any user could see them with the right flags to "ps") so it was well-known not to put anything secret there. Most (all?) of the current brand of UNIX variants have locked this down quite a while ago, which is a good thing. There are still a few old boxes kicking around though so if you're writing code that is meant to be widely deployed please don't pu…

This is the best argument for not doing this imo.

"Classic UNIX behavior was that environment variables were public (any user could see them with the right flags to "ps") so it was well-known not to put anything secret there."

The same logic applies to Windows environments and modern *nix too...

Storing private data in a public location is obviously a bad idea.

Re: Environment Variables Considered Harmful for Your Secrets

#39

Post by logicallee »

why not just split it up with an OTP, that you store in the code (or a file), then the other half in the environmental variable. combine in code (or include the file). seems like that would work. (you need both parts.)

I think this article is a response to people's practice of keeping API keys as an environmental variable so as to keep them off of the filesystem (or at least what git sees and checks in) so that they don't accidentally publish them, as happened in that article article where some gem he was using to respect .gitignore didn't work for some reason.

would this work as a solution?

Re: Environment Variables Considered Harmful for Your Secrets

#40

Post by patio11 »

sritrisna wrote: post #29

Ansible has a neat feature, called Ansible Vault, which lets you encrypt sensitive files. This in combination with dotenv-deployment works pretty well for our Rails Apps. The only thing I’m worried about is someone gaining unauthorised access to our serves and thus being able to read all the credentials stored inside the .env file especially the username & password to our externally hosted db. Probably the only way t…

If someone gets sufficient access to your server to read arbitrary files it is 99.95% possible that they also have sufficient access to just read your DB username and password straight out of the Rails application's memory. (One method, among many, would be "Attach a debugger to it." For a graphic example of what is possible with debuggers, in a format slightly easier for Rails devs to understand, see: https://github.com/ileitch/hijack)
Post reply on HN