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
