From: Mimi Zohar <zohar@linux.ibm.com>
To: Matthew Garrett <mjg59@google.com>
Cc: 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, 07 Mar 2019 15:48:10 -0500 [thread overview]
Message-ID: <1551991690.31706.416.camel@linux.ibm.com> (raw)
In-Reply-To: <CACdnJuv+d2qEc+vQosmDOzdu57Jjpjq9-CZEy8epz0ob5mptsA@mail.gmail.com>
On Wed, 2019-03-06 at 20:19 -0800, Matthew Garrett wrote:
> On Wed, Mar 6, 2019 at 5:54 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> >
> > On Wed, 2019-03-06 at 15:36 -0800, Matthew Garrett wrote:
> >
> > > > But they would have to knowingly add "get_hash" to the IMA policy and
> > > > have signed it.
> > >
> > > But in the non-signed case they'd still need to knowingly add
> > > "get_hash" to the IMA policy. Why does signing indicate stronger
> > > understanding of policy?
> >
> > Nobody is suggesting that signing the policy is a stronger indication
> > of understanding the policy. Signing the policy simply limits which
> > policies may be loaded.
>
> I'm not sure I understand the additional risk, though. Either a
> filesystem is already being measured using a full read, in which case
> adding an additional rule won't change behaviour, or it's not being
> measured at all, in which case there's no incentive for an attacker to
> add a new rule.
In an environment where the initramfs contains everything, including
the IMA policy, and is verified, then what you're saying is true - the
IMA policy doesn't need to be signed. However, the existing dracut
and systemd IMA modules read the IMA policy not from the initramfs,
but from real root. In this environment where the IMA policy is on
real root, an attacker could modify the IMA policy. I realize this is
an existing problem, not particular to "get_hash'. Unlike other
policy changes, the attestation server would have no way of detecting
this particular change.
> > There is also a difference between trusting the filesystem "read" and
> > the filesystem "get_hash" implementation, that have yet to be written.
>
> In both cases we're placing trust in the filesystem's correctness.
> It's certainly possible for the get_hash call to be broken, but that's
> something we can put additional testing into.
The call itself wouldn't be broken, but determining if the filesystem
is actually calculating/re-calculating the file hash properly or
simply returning a stored/cached value. I do see the benefit of the
filesystems being responsible for the file hash. Perhaps I'm just
being overly cautious. I'd like to hear other people's opinions.
Mimi
next prev parent reply other threads:[~2019-03-07 20:48 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 [this message]
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
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=1551991690.31706.416.camel@linux.ibm.com \
--to=zohar@linux.ibm.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 \
/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).