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

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

On Sat, 2018-01-27 at 21:46 -0500, Theodore Ts'o wrote:
> On Sat, Jan 27, 2018 at 08:19:19AM -0800, James Bottomley wrote:
> > 
> > I certainly buy this approach, and it fits well with the limited
> > data size there is in xattrs but Ted said in the initial proposal
> > the entire tree would be present in the file.  I can't see a need
> > for supplying the entire tree rather than reconstructing it but
> > maybe there's an android use case I'm not seeing (Like not wanting
> > to waste limited CPU power).
> 
> You can certainly reconstruct the Merkle tree at install time, but it
> does need to be saved on disk.  My assumption was that Merkle tree
> would be written to disk by userspace, along with the fs-verity
> header, simply because it would make things much simpler for the
> kernel, and in my view you *have* to modify userspace in some way.

OK, so we agree then that what IMA provides: a hash and potential
signature over the hash is sufficient input for what you want and does
provide existing tooling to achieve it.

> > Just so I understand the mechanics: The xattr would contain the
> > head node.  When this is written, the tree would be reconstructed
> > from the file and verified.  If it verifies, it must be stored in
> > the filesystem data somehow (or at least the lowest layer), so all
> > subsequent uses of the file can proceed from the per page hash even
> > after unmount and remount?  Then I certainly think it suits both
> > cases.
> 
> Yes.... in theory we could store the bare root hash (and some other
> bare minmum information, such as the PKCS7 signature and the elments
> of a fs-verity header) in an xattr, and setting that xattr would
> magically cause the merkle tree to be reconstructed and stored on
> disk.  But most of the file sytem developers have considered the use
> of setting or clearing xattrs to cause magically code paths to be
> executed to be an extremely bad idea.

Hang on, you've jumped straight from a discussion of ideas to an insane
implementation ... can we take a step back?  I'm thinking of three
separate things

   1. Could the signature piece of this be done in the way IMA currently
      does file signatures.  We all agree "yes" on this, since a signed
      mekle hash head is the same size as an existing IMA signature and
      therefore does fit into xattrs.
   2. Could IMA use a merkle tree for hash verification a page at a time
      as part of its implementation?  I think the answer to this is yes,
      except the hook has to be somewhere in the page fault mechanism, so
      it would need some exploration and prototyping.
   3. Could the merkle tree be cached somehow in the filesystem (probably
      as part of the filesystem implementaiton)?  You've already assumed
      "yes" for this since it's how fs-verity is proposed to work.

So the issue we could discuss is how all this is tied together.  The
implementation could be your special format file for 3. but with the
head hash signature in an xattr.  What we get back on tar would be the
ordinary file + xattr, but perhaps tar could use this to reconstruct
the magic file on untar.

I do think the "special format magic file" is a violation of the unix
principles of files being "just files" but if it's the only way, I
suppose I could be persuaded.  However, this part should also be
discussed; it does seem like, to satisfy unix principles, the merkle
tree should be provided separately from the file, possibly as a
fcntl().

James

>   And since I don't really care about the use case, I can let *you*
> try to convince Cristoph and Al Viro that his is a good idea, despite
> the general agreemnt by all file system developers that we've been
> there, done that, decided it was a really bad idea, and let's never
> ever do that again.  (And then you can get some of the "the IMA
> people are insane" taint on yourself.  :-)
> 
>     	    	    	     	 	- Ted
>