All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <jejb@linux.ibm.com>
To: Roberto Sassu <roberto.sassu@huawei.com>,
	Maurizio Drocco <maurizio.drocco@ibm.com>,
	"zohar@linux.ibm.com" <zohar@linux.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: Fri, 12 Jun 2020 10:14:19 -0700	[thread overview]
Message-ID: <1591982059.7235.29.camel@linux.ibm.com> (raw)
In-Reply-To: <380af929b2d2440a9dc35ba0b374247d@huawei.com>

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?

James


  reply	other threads:[~2020-06-12 17:14 UTC|newest]

Thread overview: 24+ 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 [this message]
2020-06-16 17:29         ` Roberto Sassu
2020-06-16 18:11           ` Mimi Zohar
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
2020-06-12  4:47 ` [PATCH] extend IMA boot_aggregate with kernel measurements kernel test robot
2020-06-12  4:47   ` kernel test robot

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=1591982059.7235.29.camel@linux.ibm.com \
    --to=jejb@linux.ibm.com \
    --cc=Silviu.Vlasceanu@huawei.com \
    --cc=dmitry.kasatkin@gmail.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 \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.