5 ms·
Unfortunately, with secrets in the OS env, you‘re one `printenv` or improperly written third party dependency that leaks env vars away from a security incident.
by HHad3 1mo ago
Unfortunately, with secrets in the OS env, you‘re one `printenv` or improperly written third party dependency that leaks env vars away from a security incident.
The env and more importantly what populates it should be secure, but security works best in layers. Sanitizing the env after loading it is a nicer middleground, k8s-style secrets materialized to files work best and are conceptually close enough to the OS env.
- tptacek 1mo agoIt's not my intuition that materializing secrets to files is a better way to protect them than just injecting them into the environment, where they don't persist.
- NewJazz 1mo agoThe env is technically still kind of a file on linux at least (through /proc). Sometimes I feel like stdin or an unlinked memory mapped file might be the best location for this stuff. Wish Linux had a cloexec+1 option, where an fd is closed after two execs, so you can set up a child process for success.
- tptacek 1mo agoOnly in the sense that everything is technically a kind of a file given access to proc.
- abofh 1mo agoDev/shm is used to materialize them, and then you have the ability to isolate the downstream code you might use from accessing it by dropping permissions or sandboxing it away from a file. You cannot really hide your environment from anything in process, since it's such a low level construct. Thus it's easier to leak environment unintentionally, leaking file contents takes effort.
- tptacek 1mo agoNot at all clear why this is a better setup than a launcher shim that pulls secrets from a secret store and injects them into the environment as the program launches --- which is a pretty normal shape for these things to take. I guess you could be thinking "subprocess inheritance" as a downside? But subprocesses often need secrets, and if you arrange for that with the filesystem you have the same problem. And, of course, files leak all the time. More to the point, though: none of this has anything to do with whether you should add secrets to your .bashrc or whatever, which is the argument I'm seeing on the thread.
- jrockway 1mo agoHave you seen this where eBPF patches secrets inside TLS send buffers? https://github.com/spinningfactory/kloak https://github.com/spinningfactory/kloak Now you have to be much more clever to leak them :)
- solarengineer 1mo ago(Edit: I need to read up on this better)
- crote 1mo agoIt doesn't need to be a traditional file. You can pass it as essentially a read-once file by using stdin. Depending on your desire for modernity, similar behavior can be obtained by leaving a file handle open for the exec-ed process to inherit, via a Unix socket, or even a lightweight TCP daemon.
- thaumasiotes 1mo ago> It's not my intuition that materializing secrets to files is a better way to protect them than just injecting them into the environment, where they don't persist. I don't really follow this reasoning. Where are you injecting the secrets from?
- nailer 1mo ago> you‘re one `printenv` or improperly written third party dependency that leaks env vars away from a security incident. Game over already if anyone can run commands or arbitrary code. Not using the environment won't help you.
- ksbd-pls-finish 1mo agoThis was about a programmer accidentally adding a debug print, or say an error page helpfully dumping environment, or logs from a third party tool, etc. Not about someone actually getting RCE just to print the environment, of course.
- chanux 1mo agosystemd-creds too, for anyone who has not found it yet like I was a week ago.
- nunez 1mo agotbf thats what a good logging lib is for, and if printenv can be run within the machine, then it's already too late