[evgpbfhnr]

> 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)

[chasil]

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]

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]

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

[sllabres]

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."

[beached_whale]

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...