How do you suppose I do this in AWS where I have several auto-balanced servers? It kind of forces you to put it in environment variables.
Why is that? Isn't that exactly the same problem whether you're using environment variables or a config file?
Environment Variables Considered Harmful for Your Secrets
101–110 of 120 posts
Re: Environment Variables Considered Harmful for Your Secrets
#102There'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.
It seems like the security for that keyring is based on uid, which can cause problems in the world of containers.
Re: Environment Variables Considered Harmful for Your Secrets
#103There'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.
The main drawback of this ( and it's a minor drawback in the larger scheme of things ) is that this isn't a portable interface and isn't available on other POSIX-ish OS's. It looks like there are key agents available for Freebsd, OS X and Illumos though.
Thanks for pointing this out.
Re: Environment Variables Considered Harmful for Your Secrets
#104Earlier quoted context omitted.
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.
Using a setuid helper (even if it's called sudo) is still starting a program as root.
Re: Environment Variables Considered Harmful for Your Secrets
#105There'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?
Stock ubuntu here has a /proc/keys file, so I think it's generally available.
Re: Environment Variables Considered Harmful for Your Secrets
#106This 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…
This article is not talking about _malicious_ applications running on your system, but unintentionally-security-weakening ones. Think of the bash RCE bug from a few months back: the problem was not that Bash was malicious, but a mismatch in expectations about how to trust the environment variables. Similarly, lots of bits of code not written with the glimmer of a notion that the environment is sensitive may end up accidentally leaking them.
This is an extension of the "don't put secrets in the query string" advice for HTTP: it's not that it's more secure: anything along the way that reads the query string can also read the post data just as easily, but that more bits of software may inadvertently leak the query string but not the post data (in logs, for instance).
Re: Environment Variables Considered Harmful for Your Secrets
#107Earlier quoted context omitted.
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.
Using a setuid helper (even if it's called sudo) is still starting a program as root.
Not necessarily; sudo on Fedora has CAP_SETUID instead of the setuid bit, so it doesn't actually run as root.
Re: Environment Variables Considered Harmful for Your Secrets
#108I 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…
Your criticisms don't seem to make much sense...
* Preventing forgery/tampering is an orthogonal issue and can be done by intrusion-detection software.
* "trivially decrypted without the key" -- How? The size of the file is not going to make any difference here.
* Of course, the key can be recovered if you have the ability to ptrace. What's your point? That's going to be true of any solution out there.
Why don't you make some constructive criticism instead of being obnoxious.
Re: Environment Variables Considered Harmful for Your Secrets
#109Installing 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.
Yes, thanks for this observation. Although inevitably, some "pets" remain...
Re: Environment Variables Considered Harmful for Your Secrets
#110How do you suppose I do this in AWS where I have several auto-balanced servers? It kind of forces you to put it in environment variables.
Why is that? Isn't that exactly the same problem whether you're using environment variables or a config file?
Because all the instances spin up with a fresh file system, but you can specify the environment variables in the AWS console.