linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Garrett <mjg59@google.com>
To: Mimi Zohar <zohar@linux.ibm.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: Tue, 5 Mar 2019 12:27:41 -0800	[thread overview]
Message-ID: <CACdnJuvhu2iepghLm4-w2XVKH+TVT1JAY=vtKtf733UXPSBPaA@mail.gmail.com> (raw)
In-Reply-To: <1551815469.31706.132.camel@linux.ibm.com>

On Tue, Mar 5, 2019 at 11:51 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> On Tue, 2019-03-05 at 10:39 -0800, Matthew Garrett wrote:
> > We can trust in-kernel filesystems to return reliable information.
> > Network filesystems have the same issue as FUSE - we're trusting that
> > the remote endpoint won't give us different information on successive
> > reads. What's the threat that's blocked by requiring signed policy
> > here?
>
> Today, IMA calculates the file hash by reading the file.  If
> "get_hash" is a generic filesystem ops, then any filesystem could
> implement it, properly or not.  sysadmins shouldn't have to review
> kernel code to understand the source of the file hash, but should be
> able to assume that unless they explicitly authorize "get_hash" usage,
> IMA reads the file and calculates the file hash.

But what's the threat? If an attacker is in a position to inject
additional IMA policy then in general they're already in a position to
violate other security assumptions. Admins who have a threat model
that includes an attacker being able to do this are already requiring
signed policy. What's the threat that requiring signed policy for this
specific option mitigates?

  reply	other threads:[~2019-03-05 20: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 [this message]
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
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='CACdnJuvhu2iepghLm4-w2XVKH+TVT1JAY=vtKtf733UXPSBPaA@mail.gmail.com' \
    --to=mjg59@google.com \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --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).