linux-kernel - Re: TPM: hibernate with IMA PCR 10

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 23 Sep 2022 16:30:47 +0300
From:   Jarkko Sakkinen <jarkko@...nel.org>
To:     Mimi Zohar <zohar@...ux.ibm.com>
Cc:     Evan Green <evgreen@...omium.org>,
        Matthew Garrett <mgarrett@...ora.tech>,
        Ken Goldman <kgold@...ux.ibm.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Daniil Lunev <dlunev@...gle.com>,
        "James E.J. Bottomley" <jejb@...ux.ibm.com>,
        linux-integrity@...r.kernel.org, Jonathan Corbet <corbet@....net>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Gwendal Grignou <gwendal@...omium.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
        "Rafael J. Wysocki" <rafael@...nel.org>
Subject: Re: TPM: hibernate with IMA PCR 10

On Wed, Sep 21, 2022 at 04:15:20PM -0400, Mimi Zohar wrote:
> On Tue, 2022-09-20 at 07:36 +0300, Jarkko Sakkinen wrote:
> > On Sat, Sep 10, 2022 at 10:40:05PM -0400, Mimi Zohar wrote:
> > > On Thu, 2022-09-08 at 08:25 +0300, Jarkko Sakkinen wrote:
> > > > On Wed, Sep 07, 2022 at 07:57:27PM -0400, Mimi Zohar wrote:
> > > > > On Wed, 2022-09-07 at 13:47 -0700, Evan Green wrote:
> > > > > > On Tue, Aug 30, 2022 at 7:48 PM Jarkko Sakkinen <jarkko@...nel.org> wrote:
> > > > > > >
> > > > > > > On Mon, Aug 29, 2022 at 02:51:50PM -0700, Matthew Garrett wrote:
> > > > > > > > On Mon, Aug 29, 2022 at 2:45 PM Ken Goldman <kgold@...ux.ibm.com> wrote:
> > > > > > > > >
> > > > > > > > > On 5/4/2022 7:20 PM, Evan Green wrote:
> > > > > > > > > > Enabling the kernel to be able to do encryption and integrity checks on
> > > > > > > > > > the hibernate image prevents a malicious userspace from escalating to
> > > > > > > > > > kernel execution via hibernation resume.  [snip]
> > > > > > > > >
> > > > > > > > > I have a related question.
> > > > > > > > >
> > > > > > > > > When a TPM powers up from hibernation, PCR 10 is reset.  When a
> > > > > > > > > hibernate image is restored:
> > > > > > > > >
> > > > > > > > > 1. Is there a design for how PCR 10 is restored?
> > > > > > > >
> > > > > > > > I don't see anything that does that at present.
> > > > > > > >
> > > > > > > > > 2. How are /sys/kernel/security/ima/[pseudofiles] saved and
> > > > > > > > > restored?
> > > > > > > >
> > > > > > > > They're part of the running kernel state, so should re-appear without
> > > > > > > > any special casing. However, in the absence of anything repopulating
> > > > > > > > PCR 10, they'll no longer match the in-TPM value.
> > > > > > >
> > > > > > > This feature could still be supported, if IMA is disabled
> > > > > > > in the kernel configuration, which I see a non-issue as
> > > > > > > long as config flag checks are there.
> > > > > > 
> > > > > > Right, from what I understand about IMA, the TPM's PCR getting out of
> > > > > > sync with the in-kernel measurement list across a hibernate (because
> > > > > > TPM is reset) or kexec() (because in-memory list gets reset) is
> > > > > > already a problem. This series doesn't really address that, in that it
> > > > > > doesn't really make that situation better or worse.
> > > > > 
> > > > > For kexec, the PCRs are not reset, so the IMA measurment list needs to
> > > > > be carried across kexec and restored.  This is now being done on most
> > > > > architectures.  Afterwards, the IMA measurement list does match the
> > > > > PCRs.
> > > > > 
> > > > > Hibernation introduces a different situation, where the the PCRs are
> > > > > reset, but the measurement list is restored, resulting in their not
> > > > > matching.
> > > > 
> > > > As I said earlier the feature still can be supported if
> > > > kernel does not use IMA but obviously needs to be flagged.
> > > 
> > > Jumping to the conclusion that "hibernate" is acceptable for non-IMA
> > > enabled kernels misses the security implications of mixing (kexec) non-
> > > IMA and IMA enabled kernels. 
> > > I would prefer some sort of hibernate marker, the equivalent of a
> > > "boot_aggregate" record.
> > 
> > Not sure if this matters. If you run a kernel, which is not aware
> > of IMA, it's your choice. I don't undestand why here is so important
> > to protect user from doing illogical decisions.
> > 
> > If you want non-IMA kernels to support IMA, CONFIG_IMA should not
> > probably even exist because you are essentially saying that any
> > kernel play well with IMA.
> 
> That will never happen, nor am I suggesting it should.
> 
> Enabling hibernate or IMA shouldn't be an either-or decision, if at all
> possible.  The main concern is that attestation servers be able to
> detect hibernation and possibly the loss of measurement
> history.  Luckily, although the PCRs are reset, the TPM
> pcrUpdateCounter is not.
> 
> I would appreciate including a "hibernate" marker, similar to the
> "boot_aggregate".

Yeah, I guess that would not do harm.

BR, Jarkko