6 ms·
Any third party code can just read your credentials file and POST it to remote server.
by kerny 6y ago
Any third party code can just read your credentials file and POST it to remote server.
- mrkeen 6y agoThat's not where the credentials are stored.
- yokaze 6y agoFile permissions allow finer granularity of access control. Environment variables are visible to any user in the system.
- fps_doug 6y agoUnset them after right after evaluation.
- loopz 6y agoNot 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.
- c0l0 6y agoLinux 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.
- josephcsible 6y ago> 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.
- yrro 6y agoBold 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!)
- josephcsible 6y agoIf the third party code runs with a different UID, then it can't read the environment either.
- yrro 6y agoUnless it has DAC override or other capabilities. Belt and braces!
- josephcsible 6y agoIf it has DAC override, then it can read your credentials file just as easily as it can the environment.
- yrro 6y agoNot if SELinux policy prevents it.