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

91–100 of 120 posts

Re: Environment Variables Considered Harmful for Your Secrets

#91

Post by kgilpin »

switch007 wrote: post #71
kgilpin wrote: post #55

Installing secrets on disk exposes them to potential leakage through backups. This is a major issue, since much less attention is typically paid to access management for backups than to production servers. Therefore I support the approach of providing secrets through the environment. Once an application has been written to get its secrets from the environment, there is a question of how the secrets are obtained. They…

Looks interesting. However, isn't the conjur API key stored in .netrc just another secret that can be easily leaked? On the distribution as a virtual appliance: is it a black box? How do I back it up? How do I upgrade it? How do I check the integrity of the secrets database?

Regarding the API key, from an operational perspective it's an improvement. The reason is it creates a separation of duties between management of the API key (responsibility of opsec), and the application credentials (responsibility of the broader ops team and in some cases the developers themselves). There is no way for the application credentials to be accidentally leaked or mis-deployed, because the policies created by opsec are always enforced.

In addition, the security team can make decisions about the management of the API key, such as:

* It can be kept off physical media (e.g.in /dev/shm)

* The process(es) by which the API keys are created and placed on the machines can be carefully managed

* A dedicated reaper/deprovisioner process can be used to retire (de-authorize) API keys once they go out of service.

Regarding the virtual appliance:

* Is it a black box? Essentially yes, although there are specific maintenance scripts on the machine (e.g. backup / restore) that you may occasionally run. For normal operation, only ports 443 and 636 (LDAPS) are open.

* How do I back it up? A standby master and read-only followers can be used to keep live copies of the database. A backup script can be used to capture full GPG-encrypted backups. A restore script will restore a backup onto a new appliance.

* How do I upgrade it? You create a standby master and followers of the new upgraded version of the appliance, and connect them to your current master. Once the standby master and followers are current with the data stream, they are promoted via DNS and serve the subsequent requests.

* How do I check the integrity of the secrets database? We have written an open-source Ruby interface to OpenSSL called Slosilo (https://github.com/conjurinc/slosilo) and subjected this library to a professional crypto audit. On the advice of the auditors, Slosilo encryption employs message authentication (cipher mode AES-256-GCM) which ensures the integrity of the secrets. Nevertheless, the Conjur appliances must obviously be afforded the highest level of protection. Unlike a multi-master system, Conjur's read-only "followers" contain only read-only copies of the secrets. So compromise of a follower cannot be used to modify secrets or authorization policies, or to confuse a master election scheme.

Re: Environment Variables Considered Harmful for Your Secrets

#93

Post by ntucker »

kiallmacinnes wrote: post #50
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/AW…

This looks really great. I watched the video and the rationale and tradeoffs they discussed sounded exactly like conversations we had back when building our system. The FUSE filesystem and agent panics are features that I wish I'd thought of.

Re: Environment Variables Considered Harmful for Your Secrets

#94

Post by [deleted] »

kgilpin wrote: post #91
switch007 wrote: post #71

Earlier quoted context omitted.

Looks interesting. However, isn't the conjur API key stored in .netrc just another secret that can be easily leaked? On the distribution as a virtual appliance: is it a black box? How do I back it up? How do I upgrade it? How do I check the integrity of the secrets database?

Regarding the API key, from an operational perspective it's an improvement. The reason is it creates a separation of duties between management of the API key (responsibility of opsec), and the application credentials (responsibility of the broader ops team and in some cases the developers themselves). There is no way for the application credentials to be accidentally leaked or mis-deployed, because the policies creat…

[deleted]

Re: Environment Variables Considered Harmful for Your Secrets

#95

Post by cirdoc98 »

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…

How do you set env vars with out a file?

Re: Environment Variables Considered Harmful for Your Secrets

#96

Post by jjmason »

phunge wrote: post #87

There's a not-widely-publicized feature of Linux that allows programs to store secrets directly in the kernel: https://www.kernel.org/doc/Documentation/security/keys.txt That has some advantages, including the guarantee that it can't be swapped to disk. Kerberos can use it for secret storage, I haven't seen it used elsewhere though. It looks like process-private storage is one of its features.

I haven't looked to hard at the docs yet, but this seems kind of awesome. Is it something that you have to build your own kernel for, or is it configurable in a prebuilt kernel?

Re: Environment Variables Considered Harmful for Your Secrets

#97

Post by switch007 »

kgilpin wrote: post #91
switch007 wrote: post #71

Earlier quoted context omitted.

Looks interesting. However, isn't the conjur API key stored in .netrc just another secret that can be easily leaked? On the distribution as a virtual appliance: is it a black box? How do I back it up? How do I upgrade it? How do I check the integrity of the secrets database?

Regarding the API key, from an operational perspective it's an improvement. The reason is it creates a separation of duties between management of the API key (responsibility of opsec), and the application credentials (responsibility of the broader ops team and in some cases the developers themselves). There is no way for the application credentials to be accidentally leaked or mis-deployed, because the policies creat…

Thank you for the reply.

Re: Environment Variables Considered Harmful for Your Secrets

#98

Post by drblast »

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.

If I set _name_ to "../../blackhat/myhackedconfig/" will that cause problems?

Re: Environment Variables Considered Harmful for Your Secrets

#99

Post by elchief »

moe wrote: post #62
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…

Classic UNIX behavior was also to have plaintext passwords in /etc/passwd, the shadow file was invented much later... But why should we jump through hoops for something that was broken over 15 years ago ? Do you still filter ping packets on your router because back in the '90s large pings would crash[1] many operating systems? [1] http://en.wikipedia.org/wiki/Ping_of_death

What, you don't run AIX 0.9?

Re: Environment Variables Considered Harmful for Your Secrets

#100

Post by elchief »

jheriko wrote: post #38
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.

It's not public. Only a given user or root can see the envvar. Same as a file.
Post reply on HN