Re: IMA on remote file systems

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

On Tue, Sep 17, 2019 at 09:30:31AM +0300, Janne Karhunen wrote:
> I might be wrong, but handling this properly would be good for the
> core IMA as well. Take an example of a memory mapped database file:
> this file will have generic write access for a group of processes.
> Now, if the attacker can create memory pressure on the host, we might
> eventually end up freeing pages from this particular file. Once this
> happens the attacker is free to modify the pages on the disk and they
> will all get eventually loaded back into the memory without no-one
> noticing.

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,
you might be able to exploit that fact by being able to force some
setuid binary to stop at some arbitrary point.  My understanding was
that they were pretty absolutist about that position, and that's one
of the reason why the original fs-verity work was completely decoupled
from IMA, and why fs-verity exists in the first place ---- if you have
gargantuan binaries with ELF debugging sections which will never get
read in normal use cases, or APK files with translation tables or
video cut scenes which are only used at when the game is first
started, or in between major sections of the game, you don't want to
delay application startup for long periods of time just to checksum
the whole darned file.

The issue about using memory pressure to push pages out to disk and
forcing a TOU/TOC security failure is the reason why Check is
interested in fs-verity.  In the original IMA design, the disk is
considered part of the Trusted Computing Base (TCB), at least while it
was spinning.  So the asssumption is the attacker wouldn't be able to
modify the disk blocks once the system was booted, and IMA merely
protected against off-line attacks (aka, "the evil maid scenario"
where the laptop or mobile device left in the hotel room gets a free
upgrade courtesy of some state intelligence agency like the MSS).  But
for NFS, the NFS server is generally not considered part of the TCB,
so the original IMA design very vulnerable to the concern you've
described.

> Could the fs-verity be plugged in as a measurement mechanism in the
> IMA? So rather than calling a hash function, call verity to measure
> and add new set of IMA hooks to report violations that arise after
> execution? IMA policy logic and functionality would be pretty much
> unchanged.

That is the plan, and it's not hard to do.  The question which I've
raised is when should we do it, given that some people believe that
pulling the entire file into memory and checksumming it at exec or
open time is a feature, not a bug.

Should we use the fs-verity merkel tree root hash as the measurement
function unconditionally if it is present?  Or does IMA want to have
some kind of tuning knob; and if so, should it be on a per-file system
basis, or globally, etc. etc.  Those are IMA design questions, and
I'll let the IMA folks decide what they want to do.

						- Ted