All of lore.kernel.org
 help / color / mirror / Atom feed
From: Janne Karhunen <janne.karhunen@gmail.com>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: "Theodore Y. Ts'o" <tytso@mit.edu>,
	Chuck Lever <chuck.lever@oracle.com>,
	linux-integrity@vger.kernel.org, Mimi Zohar <zohar@linux.ibm.com>
Subject: Re: IMA on remote file systems
Date: Wed, 18 Sep 2019 08:27:57 +0300	[thread overview]
Message-ID: <CAE=NcrZySAMJZe8Y9AfF2T3zoZqDe_HC4e7kD6eOkZMGBmSMOQ@mail.gmail.com> (raw)
In-Reply-To: <1568732169.11799.18.camel@HansenPartnership.com>

On Tue, Sep 17, 2019 at 5:57 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:

> with.  The biggest problem with fs-verity has been where to store the
> merkel tree.  However, what I've heard from IMA people is as long as
> the merkle tree storage problem gets solved satisfactorily, they're
> perfectly happy to have per page hash verification be an IMA mechanism
> because it's a simple extension of policy and an addition of a gate.

The way I see this is that the greatest asset to protect on any device
is the user data. The data security comes first, then the device
security as a mechanism to protect that same data. You could even say
that the device security is worthless when the device is empty. The
user data is almost always mutable by nature. So, would be really
great if the fs-verity metadata storage would take it into a
consideration that one day someone will want to use it for the mutable
data as well, even if Google does not want at this point in time.
Things like photos, videos are ideal use cases for the verity like Ted
pointed out.

Heck, doubt we would even have the conspiracy over the moon landings
anymore if the photos were taken with a device that could reliably
identify the device, the device user, location and the time when the
photos were taken ;)


--
Janne

  reply	other threads:[~2019-09-18  5:28 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-28 17:36 IMA on remote file systems Chuck Lever
2019-09-13 14:50 ` Chuck Lever
2019-09-15 21:42   ` Mimi Zohar
2019-09-16 16:10     ` Theodore Y. Ts'o
2019-09-16 18:16       ` Chuck Lever
2019-09-16 13:16 ` Janne Karhunen
2019-09-16 14:47   ` Chuck Lever
2019-09-17  6:30     ` Janne Karhunen
2019-09-17 12:45       ` Theodore Y. Ts'o
2019-09-17 14:18         ` Mimi Zohar
2019-09-17 14:56         ` James Bottomley
2019-09-18  5:27           ` Janne Karhunen [this message]
2019-09-18 12:50             ` Theodore Y. Ts'o
2019-09-18 15:52             ` James Bottomley
2019-09-19  6:47               ` Janne Karhunen
2019-09-18 12:37           ` Theodore Y. Ts'o
2019-09-18 14:40             ` Mimi Zohar
2019-09-18 15:49             ` James Bottomley

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='CAE=NcrZySAMJZe8Y9AfF2T3zoZqDe_HC4e7kD6eOkZMGBmSMOQ@mail.gmail.com' \
    --to=janne.karhunen@gmail.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=chuck.lever@oracle.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=tytso@mit.edu \
    --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 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.