[PATCH 3/3] ima: use fs method to read integrity data (updated patch description)

On Sun, 2017-09-17 at 08:28 -0700, Linus Torvalds wrote:

On Sun, Sep 17, 2017 at 8:17 AM, Christoph Hellwig [off-list ref] wrote:

quoted

Only for direct I/O, and IMA and direct I/O don't work together.
From ima_collect_measurement:

                if (file->f_flags & O_DIRECT) {
                        audit_cause = "failed(directio)";
                        result = -EACCES;
                        goto out;
                }

That's not the issue.

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.

Unless I'm missing something, that would only be possible with an IMA
policy rule that permits direct IO (eg. permit_directio). ?Otherwise
the direct IO is denied.

quoted

Well, that's exactly the point of the new ->integrity_read routine
I proposed and prototype.  The important thing is that it is called
with i_rwsem held because code mugh higher in the chain already
acquired it, but except for that it's entirely up to the file system.

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

Originally IMA had its own lock (iint->mutex), prior to IMA-appraisal
being upstreamed. ?With a separate lock, the iint->mutex and i_rwsem
would be taken in reverse order in process_measurements() and in the
setxattr, chown, chmod syscalls.

I'm at the airport on my way back home.

Mimi

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