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

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

On Sun, Jan 28, 2018 at 10:03:10AM -0800, James Bottomley wrote:
> 
> OK, so we agree then that what IMA provides: a hash and potential
> signature over the hash is sufficient input for what you want and does
> provide existing tooling to achieve it.

Well, that's not all IMA provides.  Remmber, the 'M' in IMA is
*measurement*.  IMA was originally about checksuming every single file
that is opened and writing it to a long.  You could suppress it by
using SELinux to tag files (using xattrs which are *not* signed) and
then writing an IMA policy which tells IMA to ignore files that belong
to a certain SE Linux tag.  This is something that I *don't* want and
today, enabling CONFIG_IMA drags all of this (including doing text
parsing of the IMA policy in the kernel, SELinux, etc.) into the
kernel.

One of my other complaints about IMA is that it's an integrated
solution, with a huge amount of complexity.  If it was only about file
signing, that would be one thing, but that's actually not the case
today.  Hence my comment about I don't want fs-verity to have a
dependency on IMA, such that we are forced to drag in all of IMA and
SELinux for anyone who wants to use use fs-verity.

This is fine; I don't want to have to dictate changes to IMA; I'd much
prefer to avoid the complexity instead of trying to reform it, since
I'm sure the IMA folks will be happy to explain why there are all
sorts of reasons why things have to be done the way it has to be done.
For example, the assertion that the latency hit at open(2) *must* be
there in order to kowtow to Microsoft because of its Trusted Boot
policies; fair enough, but *I* don't care about Trusted Boot, and it's
not fair to impose penalties on all scenarios because of a desire to
keep Microsoft happy just for one particular use case.

>    1. Could the signature piece of this be done in the way IMA currently
>       does file signatures. �We all agree "yes" on this, since a signed
>       mekle hash head is the same size as an existing IMA signature and
>       therefore does fit into xattrs.

Well.... not exactly.

It is fair to say that there are two parts of integrity metadata; and
the Merkle tree can be reconstructed at file install time.

>    2. Could IMA use a merkle tree for hash verification a page at a time
>       as part of its implementation? �I think the answer to this is yes,
>       except the hook has to be somewhere in the page fault mechanism, so
>       it would need some exploration and prototyping.

The way you are formulating things presumes that all of IMA has to be
dragged into any file integrity solution.  That's begging the
question.  As I've mentioned above, IMA has all sorts of complexity
which is currently mandatory, and I'm not volunteering to disentagling
the mess to make it be sane.  (And if you don't like that word, how
about, "designed with good taste?")

>    3. Could the merkle tree be cached somehow in the filesystem (probably
>       as part of the filesystem implementaiton)? �You've already assumed
>       "yes" for this since it's how fs-verity is proposed to work.

I don't consider this the Merkel tree to a *cache*, however because if
you don't mind a massive latency at file open tme, you can just use
the existing IMA mechanism.  So a core part of the design is that the
Merkle file is stored permanently (*not* as a cache) alongside the
file.  And if the file is renamed, the Merkle tree should come along
for the ride.

Whether the Merkle tree is reconstructed as part of the file / package
installation process, or whether the Merkle tree stored as part of the
package or streamed from the app store, etc., is an implementation
detail, and I don't think we need to prescribe one way of doing
things.  I *do* think though we should allow for possibility where
limitations on the local CPU power is such that it would be preferable
for the Merkle tree to be supplied from a remote server instead of
generated on the local system.

The problem is you have a specific use case in mind, involving the
Docker client, where you want to store the signature in an xattr, and
then not require any local changes to the Docker client --- and that's
not in my requirements set, and it was *your* statement that the
Docker client MUST NOT be modified which forced where (a) the Merkle
tree must be reconstructed in the kernel, and (b) it must be triggered
by setting the xattr.

My goal is to keep things simple, which means

* No parsing of the IMA policy as a text input in the kernel
* No Merkle tree construction in the kernel (which is also true of dm-verity)
* No magic xattr triggering

Speaking as a kernel developer, it makes a more sense to keep things
in the kernel, and do as much in userspace as possible --- and if that
means that the Docker client (or the package manager, etc.) needs a
minor change to call the userspace library, that's infinitely
preferable to keeping huge amounts of complexity in non-swappable
kernel memory --- which increases the attack surface of the kernel,
and so on.

So in my opinion, clean design of the kernel trumps the requirement of
"not one change, not one jot, in the Docker client".

It could be that the requiremnts of "keep the kernel changes simple"
and "no massive latency at file open time", means that requiremnt sets
of fs-verity and IMA are irreconcilable.  Which is fine as far as I'm
concerned.  Maybe IMA and fs-verity should be considered orthogonal
solutions.

						- Ted