Live data from Hacker News

Environment Variables Considered Harmful for Your Secrets

movingfast.io

71–80 of 120 posts

Re: Environment Variables Considered Harmful for Your Secrets

#71
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?

Re: Environment Variables Considered Harmful for Your Secrets

#72
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?

Re: Environment Variables Considered Harmful for Your Secrets

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

This is indeed an issue, though with a modern cloud based infrastructure and management systems there is no longer a need to create backups from your production servers. They can be automatically recreated and no important data is stored on them.

Re: Environment Variables Considered Harmful for Your Secrets

#74
post #45

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…

XenServer (The product from Citrix) or Xen 4.3+ support vTPM. Not sure which version of Xen that Amazon uses, but if/when they upgrade to 4.3 it should have built-in support for vTPM operations.

Re: Environment Variables Considered Harmful for Your Secrets

#75

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

[deleted]

Re: Environment Variables Considered Harmful for Your Secrets

#76

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

[deleted]

Re: Environment Variables Considered Harmful for Your Secrets

#77

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

[deleted]

Re: Environment Variables Considered Harmful for Your Secrets

#78

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

[deleted]

Re: Environment Variables Considered Harmful for Your Secrets

#79
There's a (not widely publicized) feature of Linux that enables secure key storage inside the kernel: https://www.kernel.org/doc/Documentation/security/keys.txt Storing keys in the kernel has some advantages -- your key will never get inadvertently swapped to disk etc.

It's been too long since I used it to remember the details, but I believe process-private keys are one of this API's features.

Re: Environment Variables Considered Harmful for Your Secrets

#80
post #38

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.

On Linux, at least, only root can view a process' environment via ps(1). So it's at least as secure as the filesystem from an inspection point of view.
Post reply on HN