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

91–100 of 194 posts

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

#91

Post by stackskipton »

jppittma wrote: post #86
stackskipton wrote: post #63

Earlier 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…

sigh I’m extremely competent Ops type and I know. If you mount secrets as Volume or Env Var, that’s Config file or Env var from Application PoV. We are looking at this from Application PoV.

I’ve seen Applications that do direct calls to Kubernetes API and retrieve the secret from it. So they have custom role with bindings and service account and Kubernetes client libraries.

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

#92

Post by skissane »

simonask wrote: post #4

Interesting read. Another interesting fact is that `setenv()` is fundamentally broken on POSIX, and should essentially never be called in library code. In application code, it should be called only in the absence of any alternative, and certainly before any threads have started. The reason is that `getenv()` hands out raw pointers to the variables, so overwriting a variable using `setenv()` is impossible to guard aga…

NetBSD has had getenv_r() for ages, [0] and I believe FreeBSD has very recently copied it. [1] If FreeBSD has it, macOS might eventually adopt it too. People tried already to get it into both glibc and POSIX, and it was rejected, but if it becomes more common on other platforms, that increases the chance they’ll both eventually accept it.

[0] https://man.netbsd.org/getenv_r.3

[1] https://github.com/freebsd/freebsd-src/commit/873420ca1e6e8a...

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

#93

Post by intorio »

rsyring wrote: post #40
amluto wrote: post #30

Earlier quoted context omitted.

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…

I've never tried to use ptrace-read to read secrets from a running process's memory so I can't comment on that part. I had always assumed getting secrets from a running process' memory was non-trivial and/or required root permissions but maybe that's a bad assumption. However, reading a process' environment is as trivial as: `cat /proc/123456/environ` as long as it's ran by the same user. No ptrace-read required.

You do need PTRACE access to pid 123456 in order to access that file. It is transparent to you, but the kernel will use the current task's PTRACE_ATTACH access when attempting to get that information.

By default, on most distributions, a user has PTRACE_ATTACH to all processes owned by it. This can be configured with ptrace_scope:

https://www.kernel.org/doc/Documentation/security/Yama.txt

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

#94

Post by amluto »

nine_k wrote: post #89
marcosdumay wrote: post #80

Earlier quoted context omitted.

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 thi…

Yes, you can consider all processes running under the same user as able to peek at each other's data. This is the point of running under the same uid: sharing data.One uid should be considered one security domain, with any separators inside it being guardrails, not brick walls. If you want to prevent other processes from peeking into your process, run it under a different uid. Again. that's the point. A bunch of good…

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 acting like the running user.

- Namespaces. Unless user namespaces are in use, only root can set this up. With user namespaces, anyone can do it, but the attack surface against the kernel is huge, mount namespaces are somewhat porous (infamously, /proc/self/exe is a hole), and they can be a bit resource-intensive, especially if you want to use network namespaces for anything interesting. Also, user namespaces have kind of obnoxious interactions with ordinary filesystem uids (if I'm going to run some complex containerized stack with access to a specific directory within my home directory, who should own the files in there, and how do I achieve that without root's help?). And userns without subuid doesn't isolate very strongly, and subuid need's root's help.

- Landlock. Kind of cool, kind of limited.

- Tools like Yama. On Ubuntu, with Yama enabled (the default), programs can't generally ptrace (or read /proc/self/environ) from other programs running as the same user.

In any case, once you've done something to prevent a process from accessing /proc/fd/PID for other pids belonging to the same user (e.g. pidns) and/or restricted ptrace (e.g. PR_SET_DUMPABLE), then environ gets protected.

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

#95

Post by pluto_modadic »

static secrets that you can even extract and set in a config file (or store in a secrets manager) need to go. TPM secrets that you can't extract, and public keys that you can pin without considering them "secret", along with Oauth / IAM roles, are the way to go.

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

#96

Post by cassianoleal »

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

Don’t use live system secrets and credentials when running your application locally. Then you don’t need to access the same secrets.

Keep it simple and design your applications so they’re agnostic to that fact.

It’s really not that hard, I’ve been doing this for at least 6 or 7 years. A little bit of good engineering goes a long way!

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

#98

Post by ux266478 »

cedws wrote: post #39
ux266478 wrote: post #37

Earlier quoted context omitted.

Linux's namespaces are not a security mechanism. Please do not use them as one.

I've said exactly the same thing on HN myself. However for this problem what do you suggest? Using namespaces is better than using no namespaces.

If I was actually serious about the security of a system, I'd explicitly use virtualization at-minimum. If all I wanted was a mall cop and was happy to take the risk of misconfiguration or attacks on the kernel I'd probably say something that adds a lot of extra sanity to namespaces is "good enough", like bubblewrap. I would never trust it or say that it's secure though.

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

#99

Post by dwattttt »

cbsmith wrote: post #61
monocasa wrote: post #49

Earlier quoted context omitted.

Sure. But practically the amount you leak is infinitesimal. For a lot of applications that's the right call given the rest of the posix semantics you're constrained to and the kinds and frequency of data you pass via env vars.

An infinitesimal leak becomes a problem if it is done an infinite number of times... execve seems like the preferable choice on a lot of grounds.

It would be a problem, except that the behaviour you're moving away from is a stale pointer. So surely any application that'd be leaking under that new behaviour would be crashing today.
Post reply on HN