Managing Credentials in Persistent Storage

Managing Credentials in Persistent Storage

In this lesson, you will learn how to secure sensitive credentials stored on your disk by linking filesystem-level encryption directly to the processes that need to access them.

When we store passwords, API keys, or private keys on a disk, they are "at rest." If an attacker gains physical access to the drive or manages to bypass standard file permissions, those secrets are exposed in plaintext. To mitigate this, we move beyond simple chmod permissions and integrate filesystem-level encryption with process-based access controls.

The Concept: Binding Access to Processes

The core idea is to ensure that the decryption key for a specific directory or file is only available to a verified process. We achieve this by utilizing the kernel’s ability to map security contexts to filesystem keys.

Imagine you have a microservice that requires access to a database password. Instead of leaving that file open, you use an encrypted filesystem (like fscrypt) configured so that the decryption key is only loaded into the kernel’s keyring when a process with a specific Mandatory Access Control (MAC) label—such as a SELinux or AppArmor context—is executed.

Implementation Logic

While the specific encryption implementation varies, the workflow follows this logical pattern:

1. Define the Policy: You define a security policy that limits which process (e.g., db_service_t) is permitted to call the keyctl system call.
2. Mount with Encryption: You designate a directory for secrets that is encrypted with a specific master key.
3. Process-Linked Access: When your service starts, the system's security module verifies the process integrity. Only if the process meets the requirements is the decryption key injected into that process's session keyring.

# Conceptual flow: Only the authorized process context can access the secret
# 1. Mount encrypted directory
mount -t ext4 /dev/sdb1 /secrets -o test_dummy_encryption

# 2. Process requests access, triggering a MAC check
# If the process context is 'db_service_t', the kernel releases the key.
cat /secrets/db_password.txt

By linking the availability of the file’s decryption key to the validated identity and integrity of the process, you ensure that even if a user has root access to the filesystem, they cannot read the secret unless they can also spoof the restricted process context.

Key Takeaway: To protect credentials on disk, you must tie the decryption of the data to the verified security context of the process, ensuring that the secret only exists in plaintext within the memory space of an authorized application.