> 1. Environment variables are traditionally readable by any other process in the system. There are settings you can do on modern kernels to turn this off, but

> 1. Environment variables are traditionally readable by any other process in the system. There are settings you can do on modern kernels to turn this off, but how do you know that you will always run on such a system? I think that this would require being the same user as the process you're trying to read. Access to proc/pid/environ should require that iirc. You can very easily go further by restricting procfs using hidepid. And ptrace restrictions are pretty commonplace now I think? So the attacker has to be a parent process or root. > 2. Environment variables are inherited to all subprocesses by default, unless you either unset them after you fork() (but before you exec()), or if you take special care to use execve() (or similar) function to provide your own custom-made environment for the new process. Yeah, this goes to my "easy to leak" point. Either way though you're talking about "attacker has remote code execution", which is definitely worth considering, but I don't think it matters with regards to env vs anything else. Files suffer from (1), except generally worse. File handles suffer from (2) afaik. Embedding the private key into the binary doesn't help too much if the attacker is executing with the ability to ptrace you, but it does make leaking much harder ie: you can't trick a process into dumping cleartext credentials from the env just by crashing it.