From: Chuck Lever <chuck.lever@oracle.com>
To: Janne Karhunen <janne.karhunen@gmail.com>
Cc: linux-integrity@vger.kernel.org
Subject: Re: IMA on remote file systems
Date: Mon, 16 Sep 2019 10:47:43 -0400 [thread overview]
Message-ID: <1BF68F78-FA8E-4633-9AB4-AB6E0B10DCB8@oracle.com> (raw)
In-Reply-To: <CAE=Ncrb=rh0LeDjnGYGuGJVPXG3Y1UpjD5Tw41s0zyOAaL1NKg@mail.gmail.com>
> On Sep 16, 2019, at 9:16 AM, Janne Karhunen <janne.karhunen@gmail.com> wrote:
>
> On Wed, Aug 28, 2019 at 8:36 PM Chuck Lever <chuck.lever@oracle.com> wrote:
>
>> My thought was to use an ephemeral Merkle tree for NFS (and
>> possibly other remote filesystems, like FUSE, until these
>> filesystems support durable per-file Merkle trees). A tree would
>> be constructed when the client measures a file, but it would not
>> saved to the filesystem. Instead of a hash of the file's contents,
>> the tree's root signature is stored as the IMA metadata.
>
> So the attack you are trying to guard against is that the pages that
> were evicted once and that are read back could still be integrity
> verified?
Yes, the idea would be to provide a generic mechanism for constructing
ephemeral trees such that it can be used for the purpose you describe
on behalf of file systems besides NFS; eg. FUSE, or other remote file
systems such as SMB.
In addition, I hope the mechanism would also be able to reconstruct a
partially evicted Merkle tree as well (in the cases where there is no
durable tree available).
> Handling this properly would be awesome. I don't think we have
> anything against this now, the pages that were once evicted are really
> not checked when read back.
--
Chuck Lever
next prev parent reply other threads:[~2019-09-16 14:47 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 [this message]
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
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=1BF68F78-FA8E-4633-9AB4-AB6E0B10DCB8@oracle.com \
--to=chuck.lever@oracle.com \
--cc=janne.karhunen@gmail.com \
--cc=linux-integrity@vger.kernel.org \
/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.