> On Jan 28, 2018, at 10:03 AM, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > 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(). For NFS, storing the tree or even an IMA signature in a trusted xattr is currently off the table because the protocol does not convey non-user xattrs. My interest is finding a way to get binary signing without the need of the xattr. Interestingly, Solaris puts the signature in an ELF header. That would certainly work for NFS. > 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 -- Chuck Lever
