On Fri, May 6, 2022 at 9:08 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. > > Can you (or your security team) explain why requirement 2. is needed? > > On normal systems, trusted userspace handles kernel upgrades (for example), > so it can escalate to kernel priviledges. > Our systems are a little more sealed up than a normal distro, we use Verified Boot [1]. To summarize, RO firmware with an embedded public key verifies that the kernel+commandline was signed by Google. The commandline includes the root hash of the rootfs as well (where the modules live). So when an update is applied (A/B style, including the whole rootfs), assuming the RO firmware stayed RO (which requires physical measures to defeat), we can guarantee that the kernel, commandline, and rootfs have not been tampered with. Verified boot gives us confidence that on each boot, we're at least starting from known code. This makes it more challenging for an attacker to persist an exploit across reboot. With the kernel and modules verified, we try to make it non-trivial for someone who does manage to gain root execution once from escalating to kernel execution. Hibernation would be one obvious escalation route, so we're hoping to find a way to enable it without handing out that easy primitive. [1] https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot/ > Best regards, > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
