linux-ext4 - Re: Proposal: Yet another possible fs-verity interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 12 Feb 2019 08:06:52 -0500
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Dave Chinner <david@...morbit.com>,
        Christoph Hellwig <hch@...radead.org>,
        "Darrick J. Wong" <darrick.wong@...cle.com>,
        Eric Biggers <ebiggers@...nel.org>,
        linux-fscrypt@...r.kernel.org,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net,
        James Bottomley <James.Bottomley@...senPartnership.com>
Subject: Re: Proposal: Yet another possible fs-verity interface

Hi Ted,

The context for my comments/questions was Linus' suggestions, which
you've removed.

On Tue, 2019-02-12 at 00:31 -0500, Theodore Y. Ts'o wrote:
> On Sun, Feb 10, 2019 at 09:06:55AM -0500, Mimi Zohar wrote:
> > For which files will the Merkle tree be created?  Is this for all
> > files on a per file system basis?  Or is there some sort of "flag" or
> > policy?  The original design was based on an ioctl enabling/disabling
> > a flag. In this new design, is there still an ioctl?
> 
> So for our first use case, it will be used for "privileged APK files"
> in Android.  You can think of this as a "setuid binary", effectively.

Yes, I understand that your primary goal hasn't changed.  Linus was
suggesting "the interface be made idempotent" to support "filesystems
that don't actually have any long-term storage model for the merkle
tree.  IOW, you could do the merkle tree calculation (and
verification) every time at bootup".  In that context, I asked whether
the Merkle tree file hash would be for every file on the filesystem or
not, and how to identify those files.

> > The existing file hashes included in the measurement list and the
> > audit log, are currently being used for remote attestation, forensics
> > and security analytics.

Again, the context for this comment was Linus' suggestion "each level
of the merkle tree needs to have a hash seeding thing or whatever."
Up to this point, I had assumed the Merkle tree file root hash could
be used as an identifier, similar to the file hash.  With his
suggestion, it sounds like the Merkle tree file root hash would be
system dependent, making it useless for the above usages.

> 
> IMA has a very different set primary use cases than fsverity.

We need to differentiate between IMA's method of calculating the file
hash from the IMA measurement list.  I totally agree there is a place
for both methods of calculating the file hash.  I am hoping that we
would be able to use the Merkle tree file root hash in the IMA
measurement list.  It makes no sense to have to calculate the file
hash for the measurement list, if you're using fs-verity.

Mimi