linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Roberto Sassu <roberto.sassu@huawei.com>,
	"jejb@linux.ibm.com" <jejb@linux.ibm.com>,
	Maurizio Drocco <maurizio.drocco@ibm.com>
Cc: "dmitry.kasatkin@gmail.com" <dmitry.kasatkin@gmail.com>,
	"jmorris@namei.org" <jmorris@namei.org>,
	"linux-integrity@vger.kernel.org"
	<linux-integrity@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-security-module@vger.kernel.org" 
	<linux-security-module@vger.kernel.org>,
	"serge@hallyn.com" <serge@hallyn.com>,
	Silviu Vlasceanu <Silviu.Vlasceanu@huawei.com>
Subject: Re: [PATCH] extend IMA boot_aggregate with kernel measurements
Date: Tue, 16 Jun 2020 14:11:08 -0400	[thread overview]
Message-ID: <1592331068.11061.218.camel@linux.ibm.com> (raw)
In-Reply-To: <8c44ed75fb884cad9f33c86c2d4e8a27@huawei.com>

On Tue, 2020-06-16 at 17:29 +0000, Roberto Sassu wrote:
> > From: James Bottomley [mailto:jejb@linux.ibm.com]
> > Sent: Friday, June 12, 2020 7:14 PM
> > On Fri, 2020-06-12 at 15:11 +0000, Roberto Sassu wrote:
> > > with recent patches, boot_aggregate can be calculated from non-SHA1
> > > PCR banks. I would replace with:
> > >
> > > Extend cumulative digest over ...
> > >
> > > Given that with this patch boot_aggregate is calculated differently,
> > > shouldn't we call it boot_aggregate_v2 and enable it with a new
> > > option?
> > 
> > So here's the problem: if your current grub doesn't do any TPM
> > extensions (as most don't), then the two boot aggregates are the same
> > because PCRs 8 and 9 are zero and there's a test that doesn't add them
> > to the aggregate if they are zero.  For these people its a nop so we
> > shouldn't force them to choose a different version of the same thing.
> > 
> > If, however, you're on a distribution where grub is automatically
> > measuring the kernel and command line into PCRs 8 and 9 (I think Fedora
> > 32 does this), your boot aggregate will change.  It strikes me in that
> > case we can call this a bug fix, since the boot aggregate isn't
> > properly binding to the previous measurements without PCRs 8 and 9.  In
> > this case, do we want to allow people to select an option which doesn't
> > properly bind the IMA log to the boot measurements?  That sounds like a
> > security hole to me.
> > 
> > However, since it causes a user visible difference in the grub already
> > measures case, do you have a current use case that would be affected?
> > As in are lots of people already running a distro with the TPM grub
> > updates and relying on the old boot aggregate?
> 
> I don't know how many people would be affected. However, if an
> attestation tool processes both measurement lists from unpatched kernels
> and patched kernels, keeping the same name would be a problem as it
> cannot be determined from the measurement list how boot_aggregate
> was calculated.
> 
> Anyway, I agree this should be fixed. At least, I suggest to add a Fixes tag,
> to ensure that this patch is applied to all stable kernels.

The boot aggregate on existing systems would be sha1.  Does it make
sense to limit this change to larger digests?  Anyone backporting
support for larger digests would also need to backport this change as
well.

Mimi

  reply	other threads:[~2020-06-16 18:11 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-11 19:54 [PATCH] extend IMA boot_aggregate with kernel measurements Maurizio Drocco
2020-06-12  0:29 ` Mimi Zohar
2020-06-12 14:38   ` Maurizio Drocco
2020-06-12 15:11     ` Roberto Sassu
2020-06-12 17:14       ` James Bottomley
2020-06-16 17:29         ` Roberto Sassu
2020-06-16 18:11           ` Mimi Zohar [this message]
2020-06-18 12:38             ` Roberto Sassu
2020-06-18 20:11               ` Maurizio Drocco
2020-06-18 20:11                 ` [PATCH] ima_evm_utils: extended calc_bootaggr to PCRs 8 - 9 Maurizio Drocco
2020-06-22 20:14                   ` Mimi Zohar
2020-06-22  4:50                     ` [PATCH] ima: extend boot_aggregate with kernel measurements Maurizio Drocco
2020-06-23 14:03                       ` Mimi Zohar
2020-06-23 15:57                         ` [PATCH v4] " Maurizio Drocco
2020-06-23 18:53                           ` Bruno Meneguele
2020-06-23 18:01                     ` [PATCH v2] ima_evm_utils: extended calc_bootaggr to PCRs 8 - 9 Maurizio Drocco
2020-06-23 18:13                       ` Bruno Meneguele
2020-06-24 21:17                         ` Stefan Berger
2020-06-24 21:33                           ` [PATCH] " Maurizio Drocco
2020-06-24 21:33                           ` [PATCH v2] " Bruno Meneguele
2020-06-24 21:35                             ` [PATCH v3] " Maurizio Drocco
2020-06-24 21:50                               ` Bruno Meneguele

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=1592331068.11061.218.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=Silviu.Vlasceanu@huawei.com \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=jejb@linux.ibm.com \
    --cc=jmorris@namei.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=maurizio.drocco@ibm.com \
    --cc=roberto.sassu@huawei.com \
    --cc=serge@hallyn.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).