All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
	linux-integrity@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, keyrings@vger.kernel.org
Subject: Re: [PATCH v8 4/5] IMA: Add support to limit measuring keys
Date: Thu, 21 Nov 2019 00:53:31 +0000	[thread overview]
Message-ID: <1574297611.4793.154.camel@linux.ibm.com> (raw)
In-Reply-To: <fef8fc67-643d-e579-9628-6516fd02b4db@linux.microsoft.com>

On Wed, 2019-11-20 at 16:03 -0800, Lakshmi Ramasubramanian wrote:
> On 11/20/2019 3:19 PM, Mimi Zohar wrote:
> 
> Hi Mimi,
> 
> >> The above can be used to correlate the key measurement IMA entry,
> >> ima-sig and ima-modsig entries using the same key.
> > 
> > True, but associating the public key measurement with the file
> > signature requires information from the certificate (e.g. issuer,
> > serial number, and/or subject, subject keyid).
> > 
> > For a regression test, it would be nice if the key measurement,
> > itself, contained everything needed in order to validate the file
> > signatures in the measurement list.
> 
> I am just trying to understand your asks - Please clarify:
> 
> 1, My change includes only the public key and not the entire certificate 
> information in the measured buffer.
> 
> Should I update this current patch set to measure the entire cert. Or, 
> can that be done as a separate patch set?
> 
> 2, Should a regression test be part of this patch set for the key 
> measurement changes to be accepted?

Once the key measurement is defined and upstreamed, changing it would
result in a regression.  If we think that it would change multiple
times, then perhaps the buffer measurement needs to contain some sort
of versioning.

I would very much like for a regression test to be included in this
patch set, but it isn't a requirement, as long as everything needed
for verifying a signature is included in the key measurement.

Mimi

WARNING: multiple messages have this Message-ID (diff)
From: Mimi Zohar <zohar@linux.ibm.com>
To: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
	linux-integrity@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, keyrings@vger.kernel.org
Subject: Re: [PATCH v8 4/5] IMA: Add support to limit measuring keys
Date: Wed, 20 Nov 2019 19:53:31 -0500	[thread overview]
Message-ID: <1574297611.4793.154.camel@linux.ibm.com> (raw)
In-Reply-To: <fef8fc67-643d-e579-9628-6516fd02b4db@linux.microsoft.com>

On Wed, 2019-11-20 at 16:03 -0800, Lakshmi Ramasubramanian wrote:
> On 11/20/2019 3:19 PM, Mimi Zohar wrote:
> 
> Hi Mimi,
> 
> >> The above can be used to correlate the key measurement IMA entry,
> >> ima-sig and ima-modsig entries using the same key.
> > 
> > True, but associating the public key measurement with the file
> > signature requires information from the certificate (e.g. issuer,
> > serial number, and/or subject, subject keyid).
> > 
> > For a regression test, it would be nice if the key measurement,
> > itself, contained everything needed in order to validate the file
> > signatures in the measurement list.
> 
> I am just trying to understand your asks - Please clarify:
> 
> 1, My change includes only the public key and not the entire certificate 
> information in the measured buffer.
> 
> Should I update this current patch set to measure the entire cert. Or, 
> can that be done as a separate patch set?
> 
> 2, Should a regression test be part of this patch set for the key 
> measurement changes to be accepted?

Once the key measurement is defined and upstreamed, changing it would
result in a regression.  If we think that it would change multiple
times, then perhaps the buffer measurement needs to contain some sort
of versioning.

I would very much like for a regression test to be included in this
patch set, but it isn't a requirement, as long as everything needed
for verifying a signature is included in the key measurement.

Mimi


  reply	other threads:[~2019-11-21  0:53 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-18 22:38 [PATCH v8 0/5] KEYS: Measure keys when they are created or updated Lakshmi Ramasubramanian
2019-11-18 22:38 ` Lakshmi Ramasubramanian
2019-11-18 22:38 ` [PATCH v8 1/5] IMA: Add KEY_CHECK func to measure keys Lakshmi Ramasubramanian
2019-11-18 22:38   ` Lakshmi Ramasubramanian
2019-11-18 22:38 ` [PATCH v8 2/5] IMA: Define an IMA hook " Lakshmi Ramasubramanian
2019-11-18 22:38   ` Lakshmi Ramasubramanian
2019-11-20 23:28   ` Eric Snowberg
2019-11-20 23:28     ` Eric Snowberg
2019-11-20 23:40     ` Lakshmi Ramasubramanian
2019-11-20 23:40       ` Lakshmi Ramasubramanian
2019-11-21  1:22       ` Mimi Zohar
2019-11-21  1:22         ` Mimi Zohar
2019-11-21  1:32         ` Lakshmi Ramasubramanian
2019-11-21  1:32           ` Lakshmi Ramasubramanian
2019-11-21 17:16         ` Lakshmi Ramasubramanian
2019-11-21 17:16           ` Lakshmi Ramasubramanian
2019-11-18 22:38 ` [PATCH v8 3/5] KEYS: Call the " Lakshmi Ramasubramanian
2019-11-18 22:38   ` Lakshmi Ramasubramanian
2019-11-19  1:18   ` Eric Snowberg
2019-11-19  1:18     ` Eric Snowberg
2019-11-19  1:58     ` Lakshmi Ramasubramanian
2019-11-19  1:58       ` Lakshmi Ramasubramanian
2019-11-18 22:38 ` [PATCH v8 4/5] IMA: Add support to limit measuring keys Lakshmi Ramasubramanian
2019-11-18 22:38   ` Lakshmi Ramasubramanian
2019-11-20 16:30   ` Validating key measurement Lakshmi Ramasubramanian
2019-11-20 23:19   ` [PATCH v8 4/5] IMA: Add support to limit measuring keys Mimi Zohar
2019-11-20 23:19     ` Mimi Zohar
2019-11-21  0:03     ` Lakshmi Ramasubramanian
2019-11-21  0:03       ` Lakshmi Ramasubramanian
2019-11-21  0:53       ` Mimi Zohar [this message]
2019-11-21  0:53         ` Mimi Zohar
2019-11-21  3:11         ` Lakshmi Ramasubramanian
2019-11-18 22:38 ` [PATCH v8 5/5] IMA: Read keyrings= option from the IMA policy Lakshmi Ramasubramanian
2019-11-18 22:38   ` Lakshmi Ramasubramanian

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=1574297611.4793.154.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nramas@linux.microsoft.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.