From: Ken Goldman <kgold@linux.ibm.com>
To: Tushar Sugandhi <tusharsu@linux.microsoft.com>,
	Sush Shringarputale <sushring@linux.microsoft.com>,
	linux-integrity@vger.kernel.org, zohar@linux.ibm.com,
	peterhuewe@gmx.de, jarkko@kernel.org, jgg@ziepe.ca,
	bhe@redhat.com, vgoyal@redhat.com, dyoung@redhat.com,
	kexec@lists.infradead.org, jmorris@namei.org,
	Paul Moore <paul@paul-moore.com>,
	serge@hallyn.com
Cc: code@tyhicks.com, nramas@linux.microsoft.com,
	linux-security-module@vger.kernel.org
Subject: Re: [RFC] IMA Log Snapshotting Design Proposal - unseal
Date: Wed, 6 Sep 2023 16:13:04 -0400	[thread overview]
Message-ID: <ba7d9550-03f0-9fcd-386c-382ceedbe72f@linux.ibm.com> (raw)
In-Reply-To: <1d2b1df7-aabd-8a18-a564-24399b53f3d2@linux.microsoft.com>
On 9/1/2023 5:22 PM, Tushar Sugandhi wrote:
> 
> 
> On 8/30/23 12:12, Ken Goldman wrote:
>> On 8/1/2023 3:12 PM, Sush Shringarputale wrote:
>>
>>> For remote attestation to work, the service will need to know how to
>>>  validate the snapshot_aggregate entry in the IMA log.  It will have
>>> to read the PCR values present in the template data of
>>> snapshot_aggregate event in the latest IMA log, and ensure that the
>>> PCR quotes align with the contents of the past UM_snapshot_file(s).
>>> This will re-establish the chain of trust needed for the device to
>>> pass remote attestation.  This will also maintain the ability of the
>>> remote-attestation-service to seal the secrets, if the client-server
>>>  use TPM unseal mechanism to attest the state of the device.
>>
>> I think that seal/unseal to IMA PCRs is futile.  Since boot is
>> multi-threaded, the IMA PCR is unpredictable even when valid.
> 
> True. But here we are talking about seal/unseal post boot when the
> device is in a stable state, and there are relatively less number of
> events extending IMA PCR. The value of the actual IMA PCR doesn't matter
> in this context as long as it stays the same between seal-unseal window.
Does 'relatively less number of events' really matter?  Even if there 
are only two, if the order is unpredictable, unseal fails.
> 
> If it changes between that window, the clients typically retry by
> sending the request to the service with a new stable PCR.
Does a retry help? Once the PCR has been extended to the wrong value, it 
can never get back to the correct value without a reboot.
> 
> Seal-unseal is supported by TPM spec, and is used widely. So we had to
> ensure that our proposed design wouldn't regress this existing
> functionality.
It works in the pre-OS environment, where the firmware specification 
mandates that the PCR values are repeatable. Once you're post-OS, 
multi-threaded, an unseal that includes PCR 10 is infeasible.
     prev parent reply	other threads:[~2023-09-06 20:13 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-01 19:12 [RFC] IMA Log Snapshotting Design Proposal Sush Shringarputale
2023-08-01 21:21 ` James Bottomley
2023-08-07 22:49   ` Stefan Berger
2023-08-08 12:35     ` James Bottomley
2023-08-08 13:31       ` Stefan Berger
2023-08-08 18:26         ` James Bottomley
2023-08-08 20:09           ` Stefan Berger
2023-08-08 21:41             ` James Bottomley
2023-08-10  4:43               ` Tushar Sugandhi
2023-08-10 11:43                 ` James Bottomley
2023-08-11 15:48                   ` Tushar Sugandhi
2023-08-10  4:31           ` Tushar Sugandhi
2023-08-10  4:29         ` Tushar Sugandhi
2023-08-10  1:23       ` Tushar Sugandhi
2023-08-10  1:15     ` Tushar Sugandhi
2023-08-10 14:12       ` Stefan Berger
2023-08-11 15:57         ` Tushar Sugandhi
2023-08-11 18:16           ` Stefan Berger
2023-08-10  1:03   ` Tushar Sugandhi
2023-08-11 13:14 ` Mimi Zohar
2023-08-14 21:42   ` Sush Shringarputale
2023-08-14 22:02     ` Mimi Zohar
2023-08-21 22:05       ` Sush Shringarputale
2023-08-21 23:07         ` Mimi Zohar
2023-08-29 19:34           ` Paul Moore
2023-08-29 21:03             ` Mimi Zohar
2023-08-29 21:30               ` Paul Moore
2023-08-29 21:54                 ` Mimi Zohar
2023-08-29 23:15                   ` Paul Moore
2023-08-30 20:25                     ` Mimi Zohar
2023-08-30 20:47                       ` Paul Moore
2023-08-30 21:50                         ` Mimi Zohar
2023-08-30 22:21                           ` Paul Moore
2023-08-30 22:23                             ` Paul Moore
2023-08-30 23:06                               ` Mimi Zohar
2023-08-30 23:22                                 ` Paul Moore
2023-08-31 14:01                                   ` Mimi Zohar
2023-08-31 14:43                                     ` Paul Moore
2023-08-31 16:46                                   ` Dr. Greg
2023-08-31 17:56                                     ` Paul Moore
2023-08-30 18:06 ` [RFC] IMA Log Snapshotting Design Proposal - network bandwidth Ken Goldman
2023-09-01 21:20   ` Tushar Sugandhi
2023-09-06 20:20     ` Ken Goldman
2023-09-07 20:40       ` Paul Moore
2023-08-30 18:12 ` [RFC] IMA Log Snapshotting Design Proposal - aggregate Ken Goldman
2023-09-01 22:06   ` Tushar Sugandhi
2023-09-06 20:49     ` Ken Goldman
2023-09-07 21:02       ` Paul Moore
2023-08-30 19:12 ` [RFC] IMA Log Snapshotting Design Proposal - unseal Ken Goldman
2023-08-31 15:54   ` Dr. Greg
2023-09-01 21:22   ` Tushar Sugandhi
2023-09-06 20:13     ` Ken Goldman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox
  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):
  git send-email \
    --in-reply-to=ba7d9550-03f0-9fcd-386c-382ceedbe72f@linux.ibm.com \
    --to=kgold@linux.ibm.com \
    --cc=bhe@redhat.com \
    --cc=code@tyhicks.com \
    --cc=dyoung@redhat.com \
    --cc=jarkko@kernel.org \
    --cc=jgg@ziepe.ca \
    --cc=jmorris@namei.org \
    --cc=kexec@lists.infradead.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=nramas@linux.microsoft.com \
    --cc=paul@paul-moore.com \
    --cc=peterhuewe@gmx.de \
    --cc=serge@hallyn.com \
    --cc=sushring@linux.microsoft.com \
    --cc=tusharsu@linux.microsoft.com \
    --cc=vgoyal@redhat.com \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY
  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
  Be sure your reply has a Subject: header at the top and a blank line
  before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).