Re: [Lsf-pc] [LSF/MM TOPIC] fs-verity: file system-level integrity protection

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2018-01-31 at 11:05 -0500, Theodore Ts'o wrote:
> On Tue, Jan 30, 2018 at 06:25:02PM -0500, Mimi Zohar wrote:
> > 
> > On Mon, 2018-01-29 at 18:02 -0500, Theodore Ts'o wrote:
> > > 
> > > On Mon, Jan 29, 2018 at 07:09:01AM -0500, Mimi Zohar wrote:
> > > > 
> > > > 
> > > > The LSM security_file_open hook is where fs-verity and IMA
> > > > meet.  The fs-verity Merkle tree hash signature would be
> > > > another IMA-appraisal integrity verification method.
> > > 
> > > I wasn't planning on using the file open hook for fs-verity at
> > > all, since the merkle hash signature is going to be cached in the
> > > per-file system inode --- e.g., for ext4, it would be stored in
> > > EXT4_I(inode), aka "struct ext4_inode_info".
> > 
> > Ok, so if not at open, at what point do you plan on validating the
> > merkle hash signature?
> 
> I said we would not using the LSM file_open hook.  Instead it will be
> done in ext4_file_open() or f2fs_file_open().  That's because the
> place where the key is cached is in the file system specific portion
> of the inode.  This is what I meant by EXT4_I(inode) aka struct
> ext4_inode_info.  So it does happen at file open time; it just
> doesn't use the LSM file_open hook.  One of the features of fs-verity 
> is that it does *not* require the use of the LSM infrastructure.

This is all sounding appallingly ext4/f2fs specific.  What about other
filesystems that might want this feature, how would they play?

I assume also that a write of the magic file updates the key and
signature in the inode metadata?  I suppose this also avoids the
original IMA locking problem by sorting it out below the VFS, but it
also means you have to invent mechanisms to query the key (user space
might want to know for audit purposes) and to update the key (in case
the original is compromised).

Also when you say "key" presumably you mean pointer to x509 public
certificate in a keyring somewhere, say by DN and Version or SKID?

I really think some time needs to be spent figuring out how it should
be supported in a fs generic way (at least for the user visible API)
otherwise every fs will grow its own version and we'll have a user
tooling nightmare on our hands.

James