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. > 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. > 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. > 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 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. Cheers, - Ted
