All of lore.kernel.org
 help / color / mirror / Atom feed
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: Wed, 06 Mar 2019 20:54:10 -0500	[thread overview]
Message-ID: <1551923650.31706.258.camel@linux.ibm.com> (raw)
In-Reply-To: <CACdnJut9T0xE-Q+ZAfqaRMUeBX=7w+cYE5Y7Ls1PdH-bJfv8MQ@mail.gmail.com>

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.

> If my understanding of ima_match_policy()
> correct, if there's already a measurement rule that applies to a
> filesystem then adding an additional trust_vfs rule will be ignored,
> so once the initial policy is loaded it's not possible for someone to
> transition a filesystem from a full read to using the vfs call. IE, a
> policy like:
> 
> measure
> measure fsmagic=0x46555345 trust_vfs
> 
> is still going to perform the full measurement even on FUSE.

This scenario assumes that a custom policy has already been loaded and
that there are default catchall rules.

I really do hope that anybody enabling support for loading multiple
policies requires those policies to be signed, like the builtin
appraise policy.

> 
> > > I'm happy to add this if there's a real threat model around it, but
> > > requiring signing for something other than security reasons seems like
> > > it's conflating unrelated issues.
> >
> > A colleague said, relying on the filesystem to provide the file hash
> > extends the TCB to include filesystems.
> 
> The TCB already includes filesystems - IMA's measurements are only
> accurate if the filesystem returns the same data on subsequent reads
> (assuming i_version hasn't been updated). We assert that this is true,
> but it the filesystem is outside the TCB then that assertion is
> invalid.

There is also a difference between trusting the filesystem "read" and
the filesystem "get_hash" implementation, that have yet to be written.

Mimi


  reply	other threads:[~2019-03-07  1:54 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 [this message]
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
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=1551923650.31706.258.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 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.