On Sun, Sep 17, 2017 at 08:28:40AM -0700, Linus Torvalds wrote:

The issue is that somebody else can come in - using direct IO - at the
same time as the first person is collecting measurements, and thus
race with the collector.

So now the measurements are not trustworthy any more.

Yes.  And it's always been that way with IMA.

.. and *my* point is that it's the wrong lock for actually checking
integrity (it doesn't actually guarantee exclusion, even though in
practice it's almost always the case), and so we're adding a nasty
callback that in 99% of all cases is the same as the normal read, and
we *could* have just added it with a RWF flag instead.

Is there some reason why integrity has to use that particular lock
that is so inconvenient for the filesystems it wants to check?

I'll have to defer that to Mimi - I just jumped into this whole mess
to help fixing the deadlocks we saw on XFS and NFS.

Unfortunately the whole security code is a giant mess that doesn't
document assumptions, threat models or gets any sort of verification
of those through automated testing.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html