On Tue, Sep 20, 2022 at 1:46 AM Pavel Machek <pavel@xxxxxx> wrote: > > Hi! > > > We are exploring enabling hibernation in some new scenarios. However, > > our security team has a few requirements, listed below: > > 1. The hibernate image must be encrypted with protection derived from > > both the platform (eg TPM) and user authentication data (eg > > password). > > 2. Hibernation must not be a vector by which a malicious userspace can > > escalate to the kernel. > > Why is #2 reasonable requirement? > > We normally allow userspace with appropriate permissions to update the > kernel, for example. I'll take a stab at answering this. I've also CCed one of our security folks to keep me honest and add any needed additional context. ChromeOS takes an approach of attempting to limit the blast radius of any given vulnerability as much as possible. A vulnerable system service may be running as root, but may also still be fairly constrained by sandboxing: it may not have access to all processes, the entire file system, or all capability bits. With Verified Boot [1], our kernel and rootfs are statically signed by Google (or yourself if firmware has been reflashed). Even if a full root compromise occurs, it's difficult for the attacker to persist across a reboot, since they cannot update the kernel or init flow on disk without the signing key. We do our best to lock down other escalation vectors from root to kernel as well. For instance, features like LoadPin help prevent a malicious root from simply loading up a payload via insmod. So in cases like ours, jumping from root execution to kernel execution represents a real escalation in privilege. Hibernate as it exists today represents a wide open door for root to become kernel, so we're forced to disable the Kconfigs for it. This series, along with another patch to restrict unencrypted resume, would add the guardrails we need to prevent arbitrary code from moving into the kernel via resume. -Evan [1] https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot/
