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

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

On Mon, Jan 29, 2018 at 07:09:01AM -0500, Mimi Zohar wrote:
> 
> The LSM security_file_open hook is where fs-verity and IMA meet. �The
> fs-verity Merkle tree hash signature would be another IMA-appraisal
> integrity verification method.

I wasn't planning on using the file open hook for fs-verity at all,
since the merkle hash signature is going to be cached in the per-file
system inode --- e.g., for ext4, it would be stored in EXT4_I(inode),
aka "struct ext4_inode_info".

> For those that are interested in attesting to the measurement list or
> including the file hash/signatures in the audit log, the same
> mechanisms that currently exist would be in place for using the fs-
> verity merkle tree signature. �The same mechanisms that are in place
> for including file signatures in software packages could be re-used.

This is *your* set of requiremnets, not mine.  If it's easy to do,
that's fine.  But if it doesn't, piling on extra requirements which
fs-verity can't meet is not a proof of fs-verity being not fit for
purpose, at least some use cases (e.g,. the ones we are envisioning
for fs-verity).

Again, I'm not the one arguing for IMA/fs-verity integration, and
while I am happy to work with IMA if at all possible, I am *not*
interested in compromising the fs-verity use case, or adding vast
amounts of complexity to fs-verity just to confirm to the IMA
architecture.  (That is, any complexity will need to be in optional
userspace components, such as what I've been discussing with James to
support his docker use case, or in the security/integrity subtree.  I
really *don't* want to deal with unnecessary complexity into fs/ext4,
fs/f2fs, or fs/verity.)

> Bringing it all together, what is needed?
> - the signature of the Merkle tree hash
> - a method for validating the signature
> - a method for knowing if fs-verity is enabled on the system
> A mode where fs-verity can not be disabled on the local, running
> system, once enabled.
> - lastly, a policy. �Just because a file has a signature, does not
> necessarily imply that it should be verified.

So I want to support a very simple case where the policy is simply
"the public key needed to verify the PKCS7 signing block is in a
trusted keyring".

If someone needs something more complex than the simple "key is in the
trusted keyring", I'm happy to say that the right answer is to use the
LSM hooks, and it should be straight forward to provide interfaces so
that the LSM can determine that file system supports verity and the
file has the verity bit set.  The LSM could also apply additional
restrictions (if the SELinux file type is supersekrit_t, then only a
smaller set of keys will be allowed to be used to sign the PKCS7
signature block).

Is this sufficient to allow fs-verity the ability to use IMA, if the
policy so requests it?

						- Ted

P.S.  I should note that we already have examples of data integrity
functionality that doesn't go through security/integrity.  I refer you
to diginally signed kernel modules (which do not use IMA), or
dm-verity (also not mediated through IMA).  And the existence of data
integrity functions that don't use security/integrity has not caused
the security programmers union to show up and break knuckles, just as
the Teamsters Union might have done if they had discovered that
programmers were carrying networking gear into Interop (back when it
was in San Jose) without being accredited union members.

My original intent was for fs-verity to be much like dm-verity.  That
is, something simple doesn't require a huge policy machinery just to
use it.  If others are interested in using fs-verity in a much more
complex way, or as part of a Rube Goldberg arrangement of security
modules and policies, that's fine.  I just want that mode to be
optional.