Introduction

“Just put the API Key in an Environment Variable.” Wrong. From a Physics perspective, an Environment Variable is a globally readable string in your process memory layout. It leaks to child processes. It leaks to debugging tools. It leaks to crash dumps.

This lesson explores the Physics of Secret Leakage-how data bleeds through the layers of the OS-and how tools like Vault and keyctl stop it.

---

The Physics: Why ENV Vars Leak

When you run export KEY=123 and then start a python script, that key lives in the stack of the process.

1. Child Inheritance: Every fork() copies the memory space. Your secret is cloned.
2. ProcFS Exposure: Any process running as uid can read /proc/<pid>/environ.
3. Swap to Disk: If RAM fills up, the kernel takes your “Secret” page and writes it to the hard drive (Swap). Even after reboot, the secret exists on magnetic platter.
4. Core Dumps: If the app crashes, the kernel writes all RAM to disk (core). Your key is now a text file on disk.

The Solution: mlock()

The mlock() syscall tells the kernel: “Pin this memory page to RAM. Never swap it to disk.” Secure tools (Vault, GPG, SSH-Agent) use this.

---

HashiCorp Vault: The Physics of Unsealing

How do you store the “Master Key” that encrypts all other keys? You can’t write it to disk. Vault uses Shamir’s Secret Sharing.

The Math: To reconstruct a secret $S$, you need $k$ out of $n$ parts. Imagine a polynomial curve $y = ax^2 + bx + S$. The secret $S$ is where the curve hits the Y-axis. If you have 3 points on the curve (3 Keys), you can mathematically calculate the curve and find $S$. If you have 2 points, it is physically impossible.

Operation: When Vault boots, it is sealed (Encrypted). 3 different humans must type their “Unseal Key”. Vault combines them in RAM to reconstruct the Master Key, decrypts its store, and then wipes the Master Key from RAM if it ever stops.

---

Native Linux Secrets: Kernel Keyring

Linux has a built-in Vault inside the Kernel: The Keyring. It stores keys in kernel memory, never swapping them.

# 1. Add a secret to the "User" keyring
keyctl add user mysecret "TopSecretPassword" @u

# 2. List keys
keyctl show @u
# output: 123456: --alswrv  1000  1000 user: mysecret

# 3. Read it back
keyctl print 123456

# 4. Set a timeout (Physics: Self-Destructing Memory)
keyctl timeout 123456 60

Why this is better: The secret is not in your process memory. It’s in Kernel Land. If your app creates a core dump, the secret is NOT in it.

---

Code: Memory Forensics (The Attack)

Let’s prove ENV vars are unsafe.

# 1. Start a dummy process with a secret
export PASSWORD="SENSITIVE_DATA"
python3 -c "import time; time.sleep(1000)" &
PID=$!

# 2. The Attack: Read the process environment from procfs
cat /proc/$PID/environ | tr '\0' '\n' | grep PASSWORD
# Result: PASSWORD=SENSITIVE_DATA

# 3. The Advanced Attack: Dump Memory
sudo gcore $PID
strings core.$PID | grep SENSITIVE
# Result: SENSITIVE_DATA (Found in Heap)

---

Practice Exercises

Exercise 1: The Swap Leak (Beginner)

Task: Define a secret in Python. Concept: If you disable swap (sudo swapoff -a), the risk disappears. Why do we still not trust RAM? (Answer: Cold Boot Attacks, DMA attacks).

Exercise 2: Using keyctl (Intermediate)

Task: Store a WiFi password in the kernel keyring. Action: Write a script that reads it using keyutils library, connects, and exits. Benefit: The password existed in User-Space for milliseconds only.

Exercise 3: Shamir’s Math (Advanced)

Task: Use vault operator init. Action: See it generate 5 keys. Physics: Note that no single key works.

---

Knowledge Check

1. What happens to secrets in RAM when the system swaps?
2. What syscall prevents memory from being swapped?
3. Why is /proc/self/environ dangerous?
4. How many points do you need to define a curve in Shamir’s Sharing?
5. Does keyctl store keys in User Setup or Kernel Space?

Answers

1. Written to Disk. Plaintext on the hard drive.
2. mlock() (Memory Lock).
3. It exposes secrets. Other processes with the same UID can read it.
4. Threshold (k). Usually 3 out of 5.
5. Kernel Space. Secure from core dumps.

---

Summary

• ENV Vars: Leak via ProcFS, Fork, and Exec.
• Swap: The silent persistence of RAM.
• mlock(): Pinning pages to avoid swap.
• Shamir: Mathematical impossibility of single-key compromise.

---