On Wed, Jan 31, 2018 at 12:41:13PM -0800, James Bottomley wrote: > > Like fscrypto, where most of the code is in fs/crypto, most of the > > fs-verity will be in fs/verity. There will be minimal hooks in a > > particular file system, so if another file system wants to play, then > > can do so relatively easily. > > OK, sounds good ... I notice, now I look, that fscrypt uses xattrs > (albeit hidden under the covers of get/set_context), will dm-verity use > the same trick or do people really need space in the inode? I assume you mean fs-verity above, and no, we aren't going to use xattrs because the Merkle tree won't fit in the xattr. So the plan was to put the fs-verity header, the PKCS7 signature, and the Merkle tree after i_size (rounded to a blocksize boundary). Remember, the fs-verity case we only worry about the read-ony case. The suggestion I had of putting the fs-verity header and PKCS 7 in the signature was just to carry the information for the Docker image's tar file. Before fs-verity gets ahold of it, a userspace librart would read the xattr, and use it to append the fs-verity header, PKCS 7, and the reconstructed Merkle tree to the file, and then call an ioctl to transfer it into a fs-verity protected file. > > Like dm-verity, fs-verity only supports the read-only case. So we > > don't need to worry about write updates. > > OK, but we still need to retrieve the key (if only for the "I just > found this image what did I sign the file with?" case). I assume, in- > line with fscrypt, you'll use ioctls for that. Yes. > One thought that strikes is that since you're already using xattrs > under the covers, they could simply be exposed, at least for the new > VERITY index I assume you'll be using. That way most archive systems > would pick up the signature. If you're worried about locking > inversions and other problems on write, the xattrs could be read only, > so the archive would need extra help being rewritten. As I stated above, we need to put the Merkle tree after i_size anyway, so the current plan doesn't use xattrs at all. Xattr storage space is also precious (especially if you are trying to keep all of the xattrs in the inode) so keeping an extra copy of the xattr just to make life convenient for the archive systems seems like a waste, especially for those use cases which don't *care* about backwards compatibility for archive systems that only want to deal with xattrs (and there might not be a need for any archive systems at all). And as far having magic code which reads the xattr from the storage space beyond i_size where fs-verity data is located, that's very much frowned upon. > No, as long as you do cert to signature matching by DN/Serial or SKID > it's fine if the key policy is must match and be in system keyring. > The reason being we're inching towards dumping all the UEFI certs into > the system keyring which wouldn't enhance my view of security if I knew > some random OEM could also produce acceptable signatures for my > filesystem. Another (simpler) solution would be to use a completely separate keyring for fs-verity, no? > The implementations in fscrypt look pretty close to a lot of what IMA > does, just coded under the VFS. If what you mean is whether fscrypt could have been implemented in terms of the LSM hooks, I believe the answer to this to be "no". That's because part of the LSM model is that it's not allowed to change arguments to the system call --- it can return an error which aborts the operation or return "OK, go ahead", but it's not supposed to change what the kernel operation would do or change its arguments. In the case of encryption, we are replacing the plaintext with ciphertext for writes, and replacing the ciphertext with the plaintext on reads, and that's not compatible with the original LSM model. Even if we ignored that rule, it would have been *much* more complicated to implement fscrypt in terms of the LSM hook model. > Assuming fs-verity follows the model, it may be possible to have a > generic case that just works with IMA and a specific case for a fs > where the presence of the new verity superblock operations overrides > the IMA attachment. This might actually allow building a model > where either the FS just takes care of integrity via the verity sops > or we use the generic IMA. The only complexity might be archive > restore of the image. If you want to use the tar format and xattrs to carry the integrity information, that's where things get complex. That wasn't part the original requirement set, although I understand how this gets interesting from the Docker perspective. I think it should be possible to provide ioctl's to set and get the fs-verity information, which should allow for a userspace library which could be used to do what you want. - Ted
