On Wed, 2018-01-31 at 13:46 -0500, Theodore Ts'o wrote: > On Wed, Jan 31, 2018 at 09:12:48AM -0800, James Bottomley wrote: > > > > > > This is all sounding appallingly ext4/f2fs specific. What about > > other filesystems that might want this feature, how would they > > play? > > 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 also that a write of the magic file updates the key and > > signature in the inode metadata? I suppose this also avoids the > > original IMA locking problem by sorting it out below the VFS, but > > it also means you have to invent mechanisms to query the key (user > > space might want to know for audit purposes) and to update the key > > (in case the original is compromised). > > 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. 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. > > Also when you say "key" presumably you mean pointer to x509 public > > certificate in a keyring somewhere, say by DN and Version or SKID? > > Yes. The cert might be hard-coded public key in the kernel sources; > or there might be a hard-coded CA public key, and userspace is > allowed to add new certs to the keyring so long as they are signed by > a CA cert in the system keyring. Again, I refer you to how how > signed kernel modules are managed. > > It would be possible to add something more complicated, involving > SELinux policies, or IMA policies --- but that's not something that I > need, so I view that as something that can be added later, by those > who need it. 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. > > I really think some time needs to be spent figuring out how it > > should be supported in a fs generic way (at least for the user > > visible API) otherwise every fs will grow its own version and we'll > > have a user tooling nightmare on our hands. > > Like with fscrypt, there will be a standard set of user interfaces, > most of which will be implemented in file sytem generic code. In the > case of fscrypt, the same userspace is used for ext4 and f2fs in > AOSP. > > For the generic desktop case, there is a generic userspace tooling[1] > which we are hoping will be picked up by Ubuntu as a replacement for > ecryptfs in the next year or so. (Discussions are in process; it is > not plan of record yet as far as I know.) > > [1] https://github.com/google/fscrypt Wow, that's 160k lines of go code ... OK, over the initial indigestion; I'll look at it on the 'plane to FOSDEM. > The goal for fs-verity to keep the userspace interface as simple as > possible, and of *course* it will be file system generic (it will > work for ext4 and f2fs, and it will be set up to be easy for other > interested file systems to add support for it). > > There are admittedly tradeoffs from the model model used by IMA/EVM > where the security feature is imposed on the file system code without > its knowledge or consent, and that is some minor changes are needed > in the file system code. But there are some efficiencies and some > approaches that it allows that aren't possible with one where new > file system functionality is shoehorned into an LSM. The implementations in fscrypt look pretty close to a lot of what IMA does, just coded under the VFS. 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. James
