OP: that wasn't a boring read :) thanks
Environment variables are a legacy mess: Let's dive deep into them
141–150 of 194 posts
Re: Environment variables are a legacy mess: Let's dive deep into them
#142Earlier quoted context omitted.
I think this part of Unix is exceedingly problematic. I want to be able to run program that don't have the ability to do anything that I, personally, can do. Ideally this would be doable without nasty kludges or root's help. Linux has some ways to accomplish this, for example: - seccomp. It can be done quite securely, but running general purpose software in seccomp is not necessarily a good way to prevent it from act…
It's not your (unprivileged user account's) place to decide the security posture of the entire system, that's why you're running into issues with root. Even Yama, an LSM, requires root (or de facto equivalent) for initial setup (as it should). Namespaces, if done incorrectly, can significantly increase the attack surface of the entire system (mount namespaces especially need to be treated with care) and same with reg…
> It's not your (unprivileged user account's) place to decide the security posture of the entire system, that's why you're running into issues with root.
Tell that to literally any unprivileged user who would like to run any sort of software without exposing their entire account to any possible code execution bug or malicious code in the software they're running.
> The real security barrier on most operating systems to date is the user account and if you want full isolation (modulo kernel bugs), run a process as a separate user if you're that concerned about leakage (or ideally, don't run it at all).
That a very 1980s or maybe 1990s perspective, I think. It's 2025. I have some computers. They are mine. I trust myself to administer them and do pretty much anything to them, but I would prefer not to trust all my software. Sure, I can, very awkwardly, try to isolate things by using multiple uids, but it's extremely awkward and I see no technical reason why uids are a good solution here.
And there are no shortage of technical reasons why uids are a horrible solution. I would like to run unprivileged software and delegate some degree of privilege to them -- imagine a web browser or an IDE or whatever. I, as the owner of the machine, can make a uid. But I would also like my IDE to isolate various things it runs from each other and from the IDE as a whole, and it cannot do that because it does not own the machine and should absolutely not be running as root.
Re: Environment variables are a legacy mess: Let's dive deep into them
#143...and people have to find special ways to set them. I didn't even know that pam_env existed until a recent security vulnerability announcement. It's never come to my attention before, I don't think I've ever seen it utilized. I've now made a runbook item to disable it. It's a shame that "configuration" includes undoing the fetishes and helpfulness [0][1] of others. pam-config -d --env [0] Crowded elevator atrium. Mu…
If you need realtime scheduling pam_env was the only way to do it until rtkit came out (and it still does it better than rtkit does, annoyingly).
Re: Environment variables are a legacy mess: Let's dive deep into them
#144Earlier quoted context omitted.
> but the usual procedures you find online stops working once you reboot (or close the terminal I think?) The environment isn't persistent between sessions. That means you need to make the change in a way that runs on every new session (login or new terminal window). Depending on how your system is configured: .bash_profile gets run once on every login .bashrc gets run once on every non-login new session (i.e. a new…
> Conceivably, it's possible to write a GUI tool that reads your .bashrc file What's wrong with an envfile or envdir? The envdir is kind of annoying but at least you can set permissions on the files inside it.
A lot of programs and tools will try to be cute and write into your bash files for you. I was mostly waxing philosophical at that point having gotten nerd sniped by "write a gui tool for environment variables" and "environment variables like $PATH in bash files" coming together in my head.
Re: Environment variables are a legacy mess: Let's dive deep into them
#145Earlier quoted context omitted.
Because you can't run the container, even for development outside Kubernetes. Yes, you can mount Secrets as Volumes or Env Var in Kubernetes which is fine but I'm not talking about "How you get env var/secret" but "Methods of dealing with config."
Yes you can? The container should be completely agnostic to the fact that it's running in kubernetes. You can do config the same way. Configmaps are mounted as regular files and environment variables. The application doesn't care if the configmap came from the cluster resource or a file your created on your dev machine with dev credentials. You can mount local files into the container yourself. It's docker run -v "so…
One of you is talking about mapping a secret to an environment variable and the other one of you is talking about having the work load make an API call to retrieve the secret. You’re not even talking about the same thing.
Re: Environment variables are a legacy mess: Let's dive deep into them
#146Earlier quoted context omitted.
It isn't lock in, because all the application depends on is that it gets a string it can pass to exec/the shell and then reads all data from stdout until EOF as the secret.
Sure, but let's say you have 5 secrets to get or maybe the new vault CLI does not support just stdout printing but prints JSON only. I still think this is worse than config file/Env Vars.
You can always pass echo "SECRET" as the command, so it is a strict superset of the config file. Also programs that tend to provide a command option also tend to provide a simple string option.
Re: Environment variables are a legacy mess: Let's dive deep into them
#147SRE/Sysadmin/DevOps/Whatever here, while blog didn't talk about doing anything difficult but setting ENVVAR standards, I will point out all replacements are just as frustrating especially when talking about secrets. Anything involving vaults where Application reaches out to specific secret vault like Hashicorp Vault/OpenBao/Secrets Manager quickly becomes massive vendor lock in where replacement is very difficult due…
+1 to all of this.
This is why I continue to use env vars and dotenv for configuration. They are extremely simple, work well, and are compatible with secrets managers and other secrets tooling.
Though lately I've been veering into sOps the last few years. YAML is just so nice for expressing how an app should be configured, and sops makes encrypting chunks of it so easy. Dealing with GPG keys can be challenging though, which Vault/OpenBao solve, but then lock-in becomes an issue (though less so with OpenBao).
Re: Environment variables are a legacy mess: Let's dive deep into them
#148Really, really interesting read. I use env vars daily, and it never occurred to me how they actually work. It shows how many things we take for granted have such interesting implementations. :)
Re: Environment variables are a legacy mess: Let's dive deep into them
#149Earlier quoted context omitted.
Linux security model is pretty broken without namespaces. systemd has some bells and whistles that help but if you want something better than environment variables you're naturally going to reach for cgroups.
Linux/Unix security model is that different actors are represented by different OS users. When you don't do that, it's already like inviting the burglars in your living room.
Everybody does that. How many untrusted NPM dependencies are installed as we speak? Chrome extensions? Etc.
Re: Environment variables are a legacy mess: Let's dive deep into them
#150Earlier quoted context omitted.
Linux/Unix security model is that different actors are represented by different OS users. When you don't do that, it's already like inviting the burglars in your living room.
Everybody does that. How many untrusted NPM dependencies are installed as we speak? Chrome extensions? Etc.
"Everybody" runs an operating system, where it is common to install programs by downloading random files from the internet and then clicking OK to any UAC prompt. Doesn't mean that this is not insecure.