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

[Theodore Ts'o <tytso@mit.edu>]

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