From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Matthew Garrett <mjg59@google.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>,
linux-integrity <linux-integrity@vger.kernel.org>,
Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
linux-fsdevel@vger.kernel.org, miklos@szeredi.hu
Subject: Re: [PATCH V2 3/4] IMA: Optionally make use of filesystem-provided hashes
Date: Thu, 04 Apr 2019 19:26:57 -0700 [thread overview]
Message-ID: <1554431217.24612.37.camel@HansenPartnership.com> (raw)
In-Reply-To: <CACdnJuutKe+i8KLUmPWjbFOWfrO2FzYVPjYZGgEatFmZWkw=UA@mail.gmail.com>
On Thu, 2019-04-04 at 18:50 -0700, Matthew Garrett wrote:
> On Thu, Apr 4, 2019 at 3:35 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Redundant information is always possible, but it can become
> > inconsistent and, because the hashes can't be derived from each
> > other, it's hard to tell if it is inconsistent without redoing the
> > whole hash with each method.
>
> Part of the problem here is that IMA is effectively used for two
> related but different purposes - measurement and appraisal. You
> generally want measurements to be comparable across filesystems,
> whereas appraisal doesn't need to be.
Sure, but I think the only requirement for measurement is knowing how
to reproduce them. As long as you know the algorithm the filesystem is
using ... i.e. it's recorded in the IMA log, you should be able to
verify them.
> So if we don't have comparable measurements, there's less benefit in
> performing measurement (we have no real idea what the expected
> measurements would be in advance).
As long as the algorithm used for the measurement is recorded, I don't
think there's a problem. The IMA log currently records the hash
algorithm and the actual hash, so if we take shaX to be a flat hash, we
could use shaX-merkle for fs-verity and everything would work.
> That's less important for appraisal, but arguably we don't care about
> appraisal of stuff on fs-verity backed filesystems to begin with
> because we can just attest that they're legitimate?
I think Ted mentioned they did like to sign the merkle tree to prove
the apk being installed was legitimate, so I think both measurement and
appraisal are relevant.
> > I was more wondering what, if any, problems would follow if we did
> > let the filesystem choose the hash method and simply used the top
> > merkle hash in place of the usual IMA hash?
>
> We could definitely just pass it through as a separate hash type, and
> my initial thinking was that fs-verity might be a reasonable use case
> for that, but I'm not sure that it buys us much in the IMA case.
Unifying the interfaces for measurement and appraisal sounds like a
desirable thing. IMA has just been debating measurement on mmap and
the per-page hashes of fs-verity seem to be tailor made for this.
Note: I'm not insisting on this, you just asked for other feedback and
I think it's a useful discussion.
James
next prev parent reply other threads:[~2019-04-05 2:27 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-26 21:50 Allow trusted filesystems to provide IMA hashes directly Matthew Garrett
2019-02-26 21:50 ` [PATCH V2 1/4] VFS: Add a call to obtain a file's hash Matthew Garrett
2019-02-26 21:50 ` [PATCH V2 2/4] IMA: Allow rule matching on filesystem subtype Matthew Garrett
2019-02-26 21:50 ` [PATCH V2 3/4] IMA: Optionally make use of filesystem-provided hashes Matthew Garrett
2019-02-28 16:03 ` Mimi Zohar
2019-02-28 18:05 ` Mimi Zohar
2019-02-28 21:41 ` Matthew Garrett
2019-02-28 21:59 ` Mimi Zohar
2019-02-28 22:38 ` Matthew Garrett
2019-03-04 19:52 ` Matthew Garrett
2019-03-04 20:32 ` Mimi Zohar
2019-03-04 22:10 ` Matthew Garrett
2019-03-05 13:18 ` Mimi Zohar
2019-03-05 18:39 ` Matthew Garrett
2019-03-05 19:51 ` Mimi Zohar
2019-03-05 20:27 ` Matthew Garrett
2019-03-06 12:30 ` Mimi Zohar
2019-03-06 18:31 ` Matthew Garrett
2019-03-06 22:38 ` Mimi Zohar
2019-03-06 23:36 ` Matthew Garrett
2019-03-07 1:54 ` Mimi Zohar
2019-03-07 4:19 ` Matthew Garrett
2019-03-07 20:48 ` Mimi Zohar
2019-03-07 22:41 ` Matthew Garrett
2019-04-04 21:46 ` Matthew Garrett
2019-04-04 22:18 ` James Bottomley
2019-04-04 22:26 ` Matthew Garrett
2019-04-04 22:35 ` James Bottomley
2019-04-05 1:50 ` Matthew Garrett
2019-04-05 2:26 ` James Bottomley [this message]
2019-04-05 20:55 ` Matthew Garrett
2019-04-29 22:51 ` Matthew Garrett
2019-05-02 20:25 ` Mimi Zohar
2019-05-02 22:37 ` Matthew Garrett
2019-05-02 23:02 ` Mimi Zohar
2019-05-03 6:51 ` Roberto Sassu
2019-05-03 8:17 ` Roberto Sassu
2019-05-03 12:47 ` Mimi Zohar
2019-05-03 13:20 ` Roberto Sassu
2019-02-26 21:50 ` [PATCH V2 4/4] FUSE: Allow filesystems to provide gethash methods Matthew Garrett
2019-02-27 14:26 ` Jann Horn
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=1554431217.24612.37.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=mjg59@google.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).