Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Environment variables are a legacy mess: Let's dive deep into them

allvpv.org

Post reply on HN
Print view View original

71–80 of 194 posts

Re: Environment variables are a legacy mess: Let's dive deep into them

#71

Post by 1718627440 »

vendiddy wrote: post #36
rsyring wrote: post #3

Environment variables are often used to pass secrets around. But, despite its ubiquity, I believe that's a bad practice: - On Linux systems, any user process can inspect any other process of that same user for it's environment variables. We can argue about threat model but, especially for a developer's system, there are A LOT of processes running as the same user as the developer. - IMO, this has become an even more…

Not an answer, but I do wish there was a low level primitive and a corresponding high level language construct to pass around secrets. Something like: my_secret = create_secret(value) Then ideally it's an opaque value from that point on

my_secret = getenv ("VALUE");

:-)

Re: Environment variables are a legacy mess: Let's dive deep into them

#72

Post by alexpotato »

To give an illustration of how bad this can get:

At a past firm, I was trying to debug how a particular ENV var was getting set. I started out thinking it was something simple like the user's .bashrc or equivalent.

I quickly realized that there were roughly 10 "layers" of env var loadings happening where the first couple layers were:

- firm wide

- region

- business unit

- department

- team etc etc

I ended up having to turn on a bash debug flag so that I could see exactly where the var was getting set in the layer stack.

Re: Environment variables are a legacy mess: Let's dive deep into them

#73

Post by the__alchemist »

NekkoDroid wrote: post #66
the__alchemist wrote: post #13

I get anxiety whenever I need to set an environment var on Linux. There are (somewhat distro-specific) ways that work properly, but the usual procedures you find online stops working once you reboot (or close the terminal I think?). They should add a simple env var GUI like Windows has that just works , and isn't terminal-specific. Windows has the annoyance of needing to restart the the terminal (or open a new one) f…

On systemd systems you can just either set KEY=VALUE pairs in `/etc/environment` or any file in `/etc/environment.d/` (and technically a few other places [0]). In theory it should be relatively easy to write a GUI for it by manually parsing the files. The application restarting part can't really be fixed, since environment variables aren't ever injected to a running process and can only be changed by the process itse…

Good info. I may write a script or tiny program to help with this.

Re: Environment variables are a legacy mess: Let's dive deep into them

#74

Post by Nilocshot »

stackskipton wrote: post #63
jppittma wrote: post #52

Earlier quoted context omitted.

How is the kubernetes secret API lock in? Genuinely wondering - were you trying to use that deployment yaml for something other than a kubernetes deployment? For most applications, you should be mounting the secret on your application, then you can inject it as either an environment variable or a json file that your application reads in an environment agnostic way. Then, on the backend, you can configure etcd to use…

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

This is where I like things like Tilt. If you're deploying to a k8s cluster, it's probably a good idea to do local dev in as close to a similar environment as possible.

Bit more of an initial hurdle than "just run the docker image"; however.

Re: Environment variables are a legacy mess: Let's dive deep into them

#75

Post by jhallenworld »

compiler-guy wrote: post #51
jhallenworld wrote: post #46

Eh, they are just more command line arguments, ones that go on the left side of the command instead of the right. I guess an alternative is something the Windows registry, but I'm not seeing that as a great improvement since it's less direct.

Command-line arguments aren't passed to subprocesseses, can't be inspected by arbitrary functions in the same process, and don't leak memory if they are changed.

Yes, I'm just highlighting that it's just as convenient to change them as command line parameters on a per-invocation basis. If there is a proposal for something else, it should retain this capability. Config files and something like the windows registry are much less convenient.

Re: Environment variables are a legacy mess: Let's dive deep into them

#76

Post by fullstop »

sureglymop wrote: post #48
nrds wrote: post #35

Earlier quoted context omitted.

I think it's worth specifically calling out that the right way to set environment variables is in execve() only, as communication across an exec() is the precise niche for which they are the right tool.

Why are they the right tool for that instead of passing data with program args or another way of IPC?

Program args can be seen with tools like 'ps', so passing credentials that way is a poor choice.

Re: Environment variables are a legacy mess: Let's dive deep into them

#77

Post by zokier »

compiler-guy wrote: post #51
jhallenworld wrote: post #46

Eh, they are just more command line arguments, ones that go on the left side of the command instead of the right. I guess an alternative is something the Windows registry, but I'm not seeing that as a great improvement since it's less direct.

Command-line arguments aren't passed to subprocesseses, can't be inspected by arbitrary functions in the same process, and don't leak memory if they are changed.

> can't be inspected by arbitrary functions in the same process

You can not really rely on that. The initial stack layout is well-defined at least on linux, so digging up argv is not difficult. Or just open /proc/self/cmdline

Re: Environment variables are a legacy mess: Let's dive deep into them

#78

Post by jkrejcha »

rsyring wrote: post #3

Environment variables are often used to pass secrets around. But, despite its ubiquity, I believe that's a bad practice: - On Linux systems, any user process can inspect any other process of that same user for it's environment variables. We can argue about threat model but, especially for a developer's system, there are A LOT of processes running as the same user as the developer. - IMO, this has become an even more…

> - On Linux systems, any user process can inspect any other process of that same user for it's environment variables. We can argue about threat model but, especially for a developer's system, there are A LOT of processes running as the same user as the developer.

Here's the thing though, the security model of most operating systems means that running a process as a user is acting as that user. There are some caveats (FreeBSD has capsicum, Linux has landlock, SELinux, AppArmor, Windows has integrity labels), but in the general case, if you can convince someone to run something, the program has delegated authority to act on behalf of that user. (And some user accounts on many systems may have authority to impersonate others.)

While it's by no means the only security model (there exists fully capability based operating systems out there), it's the security model that is used for most forms of computing, for better or worse. One of the consequences of this is that you can control anything within your domain. I can kill my own processes, put them to sleep, and most importantly for this, debug them. Anything I own that has secrets can grab them my ptrace/process_vm_readv/ReadProcessMemory/etc.

Re: Environment variables are a legacy mess: Let's dive deep into them

#79

Post by 1718627440 »

stackskipton wrote: post #68
1718627440 wrote: post #62

Earlier quoted context omitted.

You can have a command setting that is invoked to get the string. This way you don't have vendor login, but also don't need a separate template step.

You still need to present that to Application. So Command Line leaks worse than Env Var. Config file, see original post for problems. Env Var, see blog for problems.

No I meant a property in the application config.

For example mbsync/isync does this.

Re: Environment variables are a legacy mess: Let's dive deep into them

#80

Post by marcosdumay »

amluto wrote: post #30
rsyring wrote: post #3

Environment variables are often used to pass secrets around. But, despite its ubiquity, I believe that's a bad practice: - On Linux systems, any user process can inspect any other process of that same user for it's environment variables. We can argue about threat model but, especially for a developer's system, there are A LOT of processes running as the same user as the developer. - IMO, this has become an even more…

Since at least 2012, environment variables have been at least as secure as ordinary memory: commit b409e578d9a4ec95913e06d8fea2a33f1754ea69 Author: Cong Wang Date: Thu May 31 16:26:17 2012 -0700 proc: clean up /proc/ /environ handling You can't read another process's environment unless you can ptrace-read the process, and if you can ptrace-read the process you know all its secrets anyway. cmdline is a different story…

Just to clarify, that means that by default every process of the same user can access the variables. But it doesn't really matter because by default every process of the same user can read any secret directly from the target process anyway, right?

And that the right thing to do if you want to harden your system is to disallow ptrace-read, and not bother changing software that uses environment variables?

Because I think most people that just try will be able to read the variables of any process on their computer.

Post reply on HN