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.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Fri, May 6, 2022 at 9:08 AM Pavel Machek <[email protected]> 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
On Mon, May 9, 2022 at 6:44 PM Evan Green <[email protected]> wrote:
>
> On Fri, May 6, 2022 at 9:08 AM Pavel Machek <[email protected]> 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/
So I guess this really is an RFC.
Honestly, I need more time to go through this and there are pieces of
it that need to be looked at other people (like the TPM-related
changes).
Thanks!