Re: IMA on remote file systems

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

On Tue, Sep 17, 2019 at 09:56:09AM -0500, James Bottomley wrote:
> > There seems to be a philosophical debate about this.  Some IMA folks
> > have claimed that you want to know at the time of the binary being
> > executed, whether or not it is corrupt or not.  Their concern is that
> > if you can make a binary crash when it pages in some page of memory,,,,
>
> That's not my recollection of the IMA position.

I had *several* conversations with IMA folks, including Mimi, who very
carefully explained to me why fs-verity was bad from a security
perspective.  We also had security experts inside Google who said it
was fine, so it's fair to say that there is no unaminimity on this
issue.  (Put 4 security experts in a room, and watch 5 different
positions develop).

> I'd more say the Linux Kernel itself, at least for executables, has
> mechanisms to ensure open files aren't updated because that ends up
> causing potential I/D cache incoherence with resulting binary crashes,
> so for executables, IMA relies on this mechanism.

But that's only true because the disk is inside the TCB.  If you can
modify the disk while file is open --- for example, if the NSA has
created trojaned HDD firmware --- then assuming that the kernel can
ensure that the file can't be modified while it's being executed is
completely false.  Consider what happens if the file is stored on
iSCSI, where either (a) there is no protection of the network
connection, or (b) the iSCSI device is under the control of the
malicious attacker.

> I'd also be wary of pushing a merkle tree as a solution to the TOC/TOU
> problem because, while it's true you can appraise a page at a time
> using the lowest layer hash, unless you do a full merkle tree check on
> that hash every time, you're still vulnerable to the attacker
> corrupting both the hash and the page (especially as the merkle tree
> can be so huge, requiring that it be paged too).

If the page containing the lowest layer hash is in memory (and memory
is considered part of the TCB), then we don't need to do the full
merkle tree check.  If the lowest layer hash has been pushed out of
memory, then it has to be read from the storage device, but we might
not still have to do a full merkle tree check.  We only have to do a
check up to the merkle tree block which is still in memory.  In
practice, both for dm-verity and fs-verity, the upper layers of the
Merkle tree are will tend to be kept in memory because we can touch
them as "accessed" even though we didn't need to actually recompute
the hash of tree nodes which are still in memory.

So the Merkle tree *does* solve the TOC/TOU issue, so long as we are
careful and explicit about what are trust assumptions are.  And
certainly treating the memory as being in the TCB is fairly
uncontroversial thing to do!

						 Ted