This article does not mention that environment variables are also visible by process in /proc/*/environ (which has restrictive permissions, but is completely visible to root).

PuTTY has added a -pwfile option for use in ssh. If not exported, this interface is likely the best for non-key batch use. It seems much superior to sshpass.

The old .netrc format can be adapted for storage (which appears popular for curl), but I prefer sqlite databases, with permissions removed for all but the owner.

▲ yjftsjthsd-h 4 hours ago | parent | next [-]

> This article does not mention that environment variables are also visible by process in /proc/*/environ (which has restrictive permissions, but is completely visible to root).

What isn't visible to root? Maybe if you're willing to go down a really deep rabbit hole you can play that game, but I would generally explicitly exclude root from my threat model.

	▲	oefrha 2 hours ago \| parent [-]
		Defense in depth. Malware is software programmed to do a number of things, not all possible things (well at least until the attacker gets a shell, which is rather noisy). Scanning env vars is trivial, scanning the entire file system and traversing mount points is a bit harder, traversing all memory and guessing what’s a secret is a hell lot harder even for an interactive attacker. If you happen to include some malicious library doing dragnet mining and exfilatration of secrets, you’re more likely to dodge a bullet if you don’t have secrets in env vars than if you do.

▲ evgpbfhnr 5 hours ago | parent | prev [-]

> This article does not mention that environment variables are also visible by process in /proc/*/environ (which has restrictive permissions, but is completely visible to root).

He's explicitly not using export, so they won't show up there. Plain variables are not in the environment.

(it's good to bring up this file as well as getting inherited by child processes though)

▲ beached_whale 3 hours ago | parent | next [-]

I think that once root is the adversary, all bets are off. The simplest being /proc/*/mem or hooking a debugger up to the process and pausing it...

▲ chasil 5 hours ago | parent | prev [-]

I believe that unexported shell variables will be visible in /proc/*/mem, so it would be prudent to overwrite then unset them as soon as reasonably possible in their usage.

▲ evgpbfhnr 4 hours ago | parent [-]

mem, yes, definitely. I'm not sure how you can protect yourself from that (or root user using ptrace or equivalent debugging tool) though...

Oh, memfd_secret?

       The memory areas backing the file created with memfd_secret(2) are visible only to the processes that  have  ac‐
       cess  to the file descriptor.  The memory region is removed from the kernel page tables and only the page tables
       of the processes holding the file descriptor map the corresponding physical memory.  (Thus, the pages in the re‐
       gion can't be accessed by the kernel itself, so that, for example, pointers to the region  can't  be  passed  to
       system calls.)

▲

CableNinja 3 hours ago | parent [-]

Hm, this is interesting. What kernel version did you find this in? Im curious if this is exposed to other languages

	▲	sllabres 3 hours ago \| parent [-]
		From the man page: Linux 5.14. Before Linux 6.5, memfd_secret() was disabled by default and only available if the system administrator turned it on using "secretmem.enable=y" kernel parameter. [...] "To prevent potential data leaks of memory regions backed by memfd_secret() from a hybernation image, hybernation is prevented when there are active memfd_secret() users."