Re: IMA on remote file systems

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2019-09-18 at 08:37 -0400, Theodore Y. Ts'o wrote:
> 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.

No, it's because Linux can't let an I/D cache inconsistency develop. 
IMA merely piggy backed off that.

>   If you can modify the disk while file is open --- for example, if
> the NSA has created trojaned HDD firmware

The NSA isn't necessary ... root can write to the underlying disk even
if it has a mounted filesystem.  If you can control the system such
that you can trust root, then you can start on the NSA conspiracy
theories.

>  --- 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.

As I said, there are solutions which pull remote devices into the
security envelope, but there are reasons why a user might have
problems, with not having the security solution available topping the
list.

> > 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.

Root can modify the page cache, so this is, again, an implicit
assumption you can trust root.  If you're on the NSA conspiracy theory
then the BMC can be trojan'd and can modify memory ...

>   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.

If I've managed to push out the lower nodes, I've likely managed to
push out the upper nodes too along with most of the tree, so this is
rather weak protection.

As I said in the prior email, I think you can overcome this by forcing
a check up to the top every time you read the tree, but that's an
O(logN) effort.

> 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!

In my mind, it's no more or less controversial than the disk being in
it, which, as I said, you have to be careful about.

The general point is there is no absolute trust in anything.  However,
customers are often willing to trust some things, with different
customers willing to trust different things, so having a configurable
policy here is really the required thing.

James