Hacker News Reader

Comment by mrkeen | Hacker News Reader

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

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.

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

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.

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

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.

Unset them after right after evaluation.

That's not where the credentials are stored.

Reply on news.ycombinator.com