On 2025-08-05 11:15:35 -0000 (-0000), mharley@redhat.com wrote: [...]
In this topic (protection of secrets), the argument that the privilege escalation to root on a specific system/host undermines the need to protect sensitive data, such as secrets, is absolutely obsolete. We have to have a strong way to protect the keys that encrypt the secrets to avoid that an attacker who successfully escalates privileges to root on an owned system is able to access such sensitive data, and potentially compromise other systems. [...]
Sadly, asserting that it "has to exist" doesn't make it happen. The only common (and I use the term loosely) approach I'm aware of is to lock them in dedicated hardware, something like an HSM, so that it can be asked to decrypt credentials or sign authentication requests and return the results while the key can't itself be accessed by the operating system kernel. And even then, someone with root access to the server can still make use of the keys in the HSM, this really only addresses the data-at-rest problem. Also at the very least keep swap encrypted (unlocked by the hardware at boot, not with an encryption key that's just lying around on the rootfs), because any plaintext secrets in process memory can get paged out. Python is really not designed for secure handling of data in memory, and short of only accessing it with special C extensions or employing dodgy memset hacks there's no way I'm aware of to actually wipe the contents of strings and similar immutable data structures without terminating the process (always handling secrets with mutable types and then avoiding dynamic resizing can help). These are not cheap solutions, neither in terms of special hardware costs nor operational complexity, and so the risks posed by having credentials on disk need to outweigh the costs of mitigation for such approaches to make sense. -- Jeremy Stanley