On Mon, 2018-01-29 at 10:22 -0500, Chuck Lever wrote: > > On Jan 29, 2018, at 1:39 AM, James Bottomley <James.Bottomley@Hanse > > nPartnership.com> wrote: > > On Sun, 2018-01-28 at 10:19 -0800, Chuck Lever wrote: [...] > > > > 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. In xattr terms, IMA *is* a security label (it's under the "security." xattr namespace), so that should work for both IMA and selinux, so it sounds like the problem is solved on V4.2+ > 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). To me that's an implementation detail. The only problem is if we need to provide the tree instead of reconstructing it, how should that be done? > > > 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. Even in my use case, I want to provide a mechanism to make *some* configuration immutable, which means applying signatures to non-binary files. I expect the amount of config files which can be made immutable to grow as the OS people work on separating /etc from /run. James
