linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Mike Snitzer <snitzer@redhat.com>
Cc: Tushar Sugandhi <tusharsu@linux.microsoft.com>,
	dm-devel@redhat.com, agk@redhat.com,
	linux-integrity@vger.kernel.org, nramas@linux.microsoft.com
Subject: Re: [PATCH 1/7] dm: measure data on table load
Date: Wed, 21 Jul 2021 12:07:01 -0400	[thread overview]
Message-ID: <a6887d022d3943e0ca1efb845270fa715a60b925.camel@linux.ibm.com> (raw)
In-Reply-To: <YPhAaAyo8fKXzu5c@redhat.com>

On Wed, 2021-07-21 at 11:42 -0400, Mike Snitzer wrote:
> On Tue, Jul 20 2021 at 10:12P -0400,
> Mimi Zohar <zohar@linux.ibm.com> wrote:
> 
> > Hi Tushar, Mike, 
> > 
> > On Mon, 2021-07-12 at 17:48 -0700, Tushar Sugandhi wrote:
> > > +struct dm_ima_device_table_metadata {
> > > +       /*
> > > +        * Contains data specific to the device which is common across
> > > +        * all the targets in the table.e.g. name, uuid, major, minor etc.
> > > +        * The values are stored in comma separated list of key1=val1,key2=val2; pairs
> > > +        * delimited by a semicolon at the end of the list.
> > > +        */
> > > +       char *device_metadata;
> > > +       unsigned int device_metadata_len;
> > > +       unsigned int num_targets;
> > > +
> > > +       /*
> > > +        * Contains the sha256 hashs of the IMA measurements of the
> > > +        * target attributes key-value pairs from the active/inactive tables.
> > > +        */
> > 
> > From past experience hard coding the hash algorithm is really not a
> > good idea.
> > 
> > Mimi
> > 
> > > +       char *hash;
> > > +       unsigned int hash_len;
> > > +
> > > +};
> 
> Hi Mimi,
> 
> The dm-ima.c code is using SHASH_DESC_ON_STACK and then storing the
> more opaque result via 'hash' and 'hash_len'.
> 
> So if/when the dm-ima.c hash algorithm were to change this detail
> won't change the dm_ima_device_table_metadata structure at all right?
> But even if changes were needed this is purely an implementation
> detail correct?  Why might users care which algorithm is used by
> dm-ima to generate the hashes?
> 
> Assuming there is a valid reason for users to care about this, we can
> improve this aspect as follow-on work.. so I don't consider this a
> blocker for this patchset at this point.  Please clarify if you feel
> it should be a blocker.

This goes back to my question as to if or how the template data in
these DM critical data records are to be validated by the attestation
server.   Asumming the hash/hash_len is being stored in the IMA
measurement list, the less the attestation should need to know about
the specific kernel version the better.

thanks,

Mimi


  reply	other threads:[~2021-07-21 16:07 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-13  0:48 [PATCH 0/7] device mapper target measurements using IMA Tushar Sugandhi
2021-07-13  0:48 ` [PATCH 1/7] dm: measure data on table load Tushar Sugandhi
2021-07-21  2:12   ` Mimi Zohar
2021-07-21 15:42     ` Mike Snitzer
2021-07-21 16:07       ` Mimi Zohar [this message]
2021-07-21 21:17         ` Mimi Zohar
2021-07-29 19:58           ` Tushar Sugandhi
2021-07-13  0:48 ` [PATCH 2/7] dm: measure data on device resume Tushar Sugandhi
2021-07-13  0:49 ` [PATCH 3/7] dm: measure data on device remove Tushar Sugandhi
2021-07-13  0:49 ` [PATCH 4/7] dm: measure data on table clear Tushar Sugandhi
2021-07-13  0:49 ` [PATCH 5/7] dm: measure data on device rename Tushar Sugandhi
2021-07-13  0:49 ` [PATCH 6/7] dm: update target specific status functions to measure data Tushar Sugandhi
2021-07-13  1:06   ` Alasdair G Kergon
2021-07-14 20:23     ` Tushar Sugandhi
2021-07-13  0:49 ` [PATCH 7/7] dm: add documentation for IMA measurement support Tushar Sugandhi
2021-07-21  2:33   ` Mimi Zohar
2021-07-24  7:25     ` Tushar Sugandhi
2021-07-26 16:33       ` Mimi Zohar
2021-07-26 18:28         ` Tushar Sugandhi
2021-07-14 11:32 ` [dm-devel] [PATCH 0/7] device mapper target measurements using IMA Thore Sommer
2021-07-14 20:20   ` Tushar Sugandhi
2021-07-27 10:18     ` Thore Sommer
2021-07-27 20:33       ` Alasdair G Kergon
2021-07-28  3:10         ` Tushar Sugandhi
2021-07-28 17:14           ` Thore Sommer
2021-07-29 17:32             ` Tushar Sugandhi
2021-07-28 17:34         ` Thore Sommer
2021-07-28 21:33       ` Alasdair G Kergon
2021-08-02 10:45         ` Thore Sommer
2021-07-29 19:24       ` Tushar Sugandhi
2021-08-02 10:38         ` Thore Sommer
2021-07-20 21:27 ` Mike Snitzer

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=a6887d022d3943e0ca1efb845270fa715a60b925.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=agk@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=nramas@linux.microsoft.com \
    --cc=snitzer@redhat.com \
    --cc=tusharsu@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 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).