what are the other alternatives to ENV that are more preferred in terms of security?
Comment on Disclosure of sensitive credentials and configuration in containerized deployments - ownCloud
sudneo@lemmy.world 10 months agoThe only thing that makes this case worse in docker is that more info is in ENV variables. The vulnerability has nothing to do with containers though, and using ENV variables to provide sensitive data is in general a bad decision, since they can be leaked to any process with /proc access.
Unfortunately, ENV is still a common way which people use to pass data to applications inside containers, but it is not in any way a requirement imposed by the tech.
inspxtr@lemmy.world 9 months ago
synestine@sh.itjust.works 9 months ago
A named volume for the config directory for one.
sphericth0r@kbin.social 9 months ago
That's just as insecure lol, env bars are far better
sudneo@lemmy.world 9 months ago
In general, a mounted file would be better, because it is easier to restrict access to filesystem objects both via permissions and namespacing. Also it is more future proof, as the actual ideal solution is to use secret managers like Vault (which are overkill for many hobbyist), which can render secrets to files (or to ENV, but same security issue applies here).
sphericth0r@kbin.social 9 months ago
It's probably best to look at what the devops industry is embracing, environment variables are as secure as any of the alternatives but poor implementations will always introduce attack vectors. Secret management stores require you to authenticate, which requires you to store the credential for it somewhere - no matter what there's no way to secure an insecure implementation of secrets access
sudneo@lemmy.world 9 months ago
They are not as secure, because there are less controls for ENV variables. Anybody in the same PID namespaces can cat /proc/PID/environ and read them. For files (say, config file) you can use mount namespaces and the regular file permissions to restrict access.
Of course you can mess up a secret implementation, but a chmod’d 600 file from another user requires some sort of arbitrary read vulnerability or privilege escalation (assuming another application on the same host is compromised, for example). If you get low-privileged access to the host, chances are you can dump the ENV for all processes.
Security-wise, ENV variables are worse compared to just a mounted config file, for example.
TCB13@lemmy.world 9 months ago
No, but it only happens because this tech exists in the first place and things got way more cumbersome and way overcomplicated than they should be.
sudneo@lemmy.world 9 months ago
Absolutely not. Many applications used ENV variables for sensitive stuff even before. Let’s remember that the vulnerability here is being able to execute phpinfo remotely.
Containerization can do good for security, in general.
TCB13@lemmy.world 9 months ago
This is just a bad practice that was popularized by CI/CD solutions and later on by containers. I’m not saying containers aren’t good for security, what I’m saying is that they’re misused and abused and that images shouldn’t even be a thing. Isolation is great, blindingly trusting images made by someone and/or having people that don’t have any basic knowledge of security nor infrastructure suddenly being able to deploy complex solutions with a click ends up in situations like this.
sudneo@lemmy.world 9 months ago
OK, but how do you solve the problem? Trusting an image is not so different than downloading a random deb and installing it, which maybe configures a systemd unit as well. If not containers you still have to run the application somehow.
Ultimately my point is that containers allow you to do things securely, exactly like other tools. You don’t even have to trust the image, you can build your own. In fact, almost every tool I add to my lab, I end up opening a PR for a hardened image and a tighter helm chart.
In any case, I would not expose such application outside of a VPN, which is a blanket security practice that most selhosters should do for most of their services…
Anonymouse@lemmy.world 9 months ago
I’m using Kubernetes and many of the apps that I use require environment variables to pass secrets. Another option is the pod definition, which is viewable by anybody with read privileges to K8s. Secrets are great to secure it on the K8s side, but the application either needs to read the secret from a file or you build your own helm chart with a shell front end to create app config files on the fly. I’m sure there are other options, but there’s no “one size fits all” type solution.
The real issue here is that the app is happy to expose it’s environment variables with no consideration given to the fact that it may contain data that can be misused by bad actors. It’s security 101 to not expose any more than the user needs to see which is why stack dumps are disabled on production implementations.
sudneo@lemmy.world 9 months ago
The problem is in fact in the applications. If these support loading secrets from a file, then the problem does not exist. Even with the weak secrets implementation in kubernetes, it is still far better than ENV variables.
The disappointing thing is that in many “selfhost” apps, often the credentials to specify are either db credentials or some sort of initial password, which could totally be read from file or be generated randomly at first run.
I agree that the issue is information disclosure, but the problem is that ENV variables are stored in memory, are accessible to many other processes on the same system, etc. They are just not a good way to store sensitive information.