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

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

On Tue, Jan 30, 2018 at 06:25:02PM -0500, Mimi Zohar wrote:
> On Mon, 2018-01-29 at 18:02 -0500, Theodore Ts'o wrote:
> > 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".
> 
> Ok, so if not at open, at what point do you plan on validating the
> merkle hash signature?

I said we would not using the LSM file_open hook.  Instead it will be
done in ext4_file_open() or f2fs_file_open().  That's because the
place where the key is cached is in the file system specific portion
of the inode.  This is what I meant by EXT4_I(inode) aka struct
ext4_inode_info.  So it does happen at file open time; it just doesn't
use the LSM file_open hook.  One of the features of fs-verity is that
it does *not* require the use of the LSM infrastructure.

> I agree with you that the integrity architecture needs to be easily
> extendsible to support different integrity authentication methods.
> �The list, below, is a set of fs-verity functions needed to be
> exported for IMA. �Hopefully I didn't miss anything.

Just to be clear, who is signing up to do all of this work to enable
fs-verity for IMA?  In particular, if you and James are asking *me* to
do all of this development work, when I have no need for any of these
benefits, I'm going to have to decline the honor.  I'm happy to try to
modify the design to make it easier for IMA to use fs-verity.  That's
different from actually implementing it.

> > 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".
> 
> Which trusted keyring? �How is the keyring populated? �What prevents
> other keys from being added to that keyring?

It will probably be a separate keyring, but in theory we could use the
keyring used to validate signed kernel modules.  There are a number of
different ways the policy for signed kernel modules can be
configured[1], and the same would be true for fs-verity.  (The reason
for a separate kernel keyring is to allow for a separation between
those keys trusted to sign kernel modules, and those trusted to sign
for fs-verity.)

[1] https://01.org/linuxgraphics/gfx-docs/drm/admin-guide/module-signing.html

> So the implied policy is that no signatures will be verified unless
> userspace turns the bit on. �So you're trust is based in userspace.

For the initial use case that we're interested in, yes.  The check to
make sure the verity bit is enabled for a small set of privileged
APK's will be done by the AOSP userspace, and the AOSP userspace lives
in a read-only system partition which is protected using dm-verity.
(And the keys for dm-verity are protected using asigned bootloader; it
is possible to do data integrity without using IMA/EVM, and millions
and millions of Android devices are doing in this way.)


The problem we're trying to solve is that in order to allow for the
privileged APK's to be upgraded more frequently, they are stored in
the /data partition, which is encrypted; however, fs-crypt does not
provide data integrity guarntees.  fs-verity allows us to protect
those APK's (which are equivalent in power to software in the system
partition, being privileged APK's).

Note also that an APK will often have large number of translations
that will never be used on a particular device, so doing full check of
the entire APK will mean doing unneeded work.  Obviously you have to
trade off the time of doing sequential reads versus the random reads
for doing on-demand Merkle tree checks, but if you have translation
resources for Russian, Chinese, French, Spanish, etc, and the only
language used on a particular device is English, then the on-demand
checks can often be far more efficient, especially if the one of the
figures of merit is how long it takes for an application to start
painting the first pixel after the user clicks on its icon.

> > 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).
> 
> Interesting, so there is an additional policy limiting which keys may
> be used based on an LSM labels, if so desired.

If someone implements it, yes.  If there is a business case where the
benefits outweighs the costs, and the headcount can be funded, it
would happen.  However, having spent time trying to understand the
IMA/EVM/LSM/SELinux architecture, I've spent enough time to decide
it's not something I would do on my own time, for fun.  :-)

						- Ted