Hacker News Reader

Comment by mrkeen | Hacker News Reader

I don't know about https://12factor.net either.

But I was assigned a task last year to remove configuration from environment variables (for security reasons). I deployed my work to 'production'.

View on HN

Linux is usually configured to not allow processes from another user to read /proc/$pid/environ. At least a production machine should be.

Configuration files are resistant to this as you note, but command-line arguments are not (--password=1234 will show up in ps for everyone).

What security concerns did that alleviate?

Any third party code in our system can just read whatever's in the environment and POST it to some remote server.

Any third party code can just read your credentials file and POST it to remote server.

File permissions allow finer granularity of access control. Environment variables are visible to any user in the system.

Unset them after right after evaluation.

Not in any multi-user multi-process OS. You set environment variables in a process (ie. shell/CMD.EXE) and spawn child process (the program) from that parent. The environment variables will only be visible to those two processes.

Linux disagrees; try

    strings /proc/*/environ

to see for yourself.

On Solaris/SunOS, you could use `pargs -e $PID`. And so on.

Having separate UIDs to run your processes A and B under shields either one from peeking at the other's environment, though. UNIX DAC is simple and powerful enough for MOST security concerns, I would argue.

> Environment variables are visible to any user in the system.

This is completely false in any modern OS. You can only see environment variables of your own processes.

That's not where the credentials are stored.

Bold of you to assume my third party code runs with the same UID and SELinux label as my credentials-handling code.

(I wish, it's April 1 after all!)

If the third party code runs with a different UID, then it can't read the environment either.

Unless it has DAC override or other capabilities. Belt and braces!

If it has DAC override, then it can read your credentials file just as easily as it can the environment.

Not if SELinux policy prevents it.

Avoiding environment variables reduces the risk but doesn't eliminate it. The secrets still live in memory in some form, correct? However, it does help to eliminate generic attempts to exfiltrate environment variables.

Tight control of egress network traffic is better but more difficult to implement.

Well, sure, you shouldn't be putting secrets or other sensitive data in environment variables. But garden-variety configuration is fine to put in env vars. Seems like whoever assigned you this task didn't really know what they were doing.

Oops, I've been putting secrets in environment variables since I can remember. Your comment piqued my curiousity on why this is a bad idea.

Found this:

https://diogomonica.com/2017/03/27/why-you-shouldnt-use-env-...

https://security.stackexchange.com/questions/197784/is-it-un...

Reply on news.ycombinator.com