> On Jan 29, 2018, at 1:39 AM, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Sun, 2018-01-28 at 10:19 -0800, Chuck Lever wrote: >> >>> >>> On Jan 28, 2018, at 10:03 AM, James Bottomley <James.Bottomley@Hans >>> enPartnership.com> 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. > > OK, but are you sure fixing that with a binary format interpreter is > the correct thing to do? I think it should work both for IMA and > selinux if you go this road, right? NFSv4.2 does have the ability to convey security labels between NFS client and server. One thing that has been suggested is to define a security label that can store information such as file capabilities. The same tactic could be used to store a limited size item such as the signed root hash. Given the ability to reconstitute the Merkle tree instead of storing it, that might be enough to allow NFS to play (using the mechanism that you and Ted are developing here). >> 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. > > That would work ... sort of the ELF equivalent of authenticode. > However, it only works for binaries ... what about the IMA uses of non > binary files? Fair enough, though I'm not sure Oracle (for example) has a non- executable use case. We are focusing largely on similar virtualization use cases as yours. > James > > >> >>> >>> 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 -- Chuck Lever
