On Thu, Jan 25, 2018 at 08:50:35PM -0800, James Bottomley wrote: > > Sorry, I meant PKCS7. It would be a restricted PKCS7 mode, using a > > detached signature. My plan was to reuse the existing code we > > already have written for signed kernel modules. > > OK, so presumably the signature would be over the part of the tree at > the end of the file (so the tree is already reduced to a hashable > binary representation) and this is verified upon write, after which the > hash tree is trusted. The signature would cover the fs-verity header including the "root hash" of the merkle tree (e.g., the hash of the first block of the merkle tree), yes. > > Currently container images are simple tar files and one of the main > value adds of docker as a tool is the simplicity of the image creation > process. That process depends on standard tools like tar to create the > image, so I was trying to fit this proposal into that process. The goal of fs-verity is protect arbitrary files without breaking the backwards compatibility of those that *read* the file. So for example, an APK file is downloaded and verified at the intial download --- and never verified again. It is *used* many times after the initial download (and hence, potentially after an evil maid attack), and this is done by many different tools, including by code inside the APK itself. So it is not feasible to change the tools that read the APK, which means we can't make any backwards-incompatible changes to the file itself. However, changing the tools that *establish* the locally verified copy is considered completely fair game. I'll note that this is true no matter what system you use. If you are using IMA, after the file is downloaded, you still have to set the magic "trusted xattr" (which, I will note, requires root access since it is a trusted root access). So you have to make at least *some* changes to the code path which writes the file that you want to be integrity protected. In the case of IMA, this includes code that has to run as root. For fs-verity, there would be a userspace library that would append the fs-verity information, and then call the fs-verity ioctl to set up the protection. Since the data is self-verifying, due to the digital signature, using setting the verity bit does not require root privileges. The kernel will check and make sure it is signed by a trusted key, of course, but it will simply reject the attempt to enable fs-verity if the cert is not present on a trusted keyring. > OK, so that worries me a bit more. I assume we could use this ioctl to > recreate the file by extracting the tree and thence do a conversion to > tar format so that the untarred file has the signed hash, but just > doing a tar of the directory won't work, so docker save is going to > have to be seriously altered to work with this. Docker save was going to have to be altered to use IMA, anyway. So I don't see that as being any more difficult. Whether you have to have root to set the magic IMA trusted xattr, or you call a userspace library, there isn't much difference between those two. - Ted
