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

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

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