[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFyrZ=YsfNc1vp=vArNgotLXGPr4F6uZiz22Uj2XHGUvaw@mail.gmail.com>
Date: Sun, 17 Sep 2017 08:28:40 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Christoph Hellwig <hch@...radead.org>
Cc: Mimi Zohar <zohar@...ux.vnet.ibm.com>,
LSM List <linux-security-module@...r.kernel.org>,
Christoph Hellwig <hch@....de>,
linux-ima-devel@...ts.sourceforge.net,
James Morris <jmorris@...ei.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Matthew Garrett <mjg59@...f.ucam.org>,
Jan Kara <jack@...e.com>, "Theodore Ts'o" <tytso@....edu>,
Andreas Dilger <adilger.kernel@...ger.ca>,
Jaegeuk Kim <jaegeuk@...nel.org>, Chao Yu <yuchao0@...wei.com>,
Steven Whitehouse <swhiteho@...hat.com>,
Bob Peterson <rpeterso@...hat.com>,
David Woodhouse <dwmw2@...radead.org>,
Dave Kleikamp <shaggy@...nel.org>,
Ryusuke Konishi <konishi.ryusuke@....ntt.co.jp>,
Mark Fasheh <mfasheh@...sity.com>,
Joel Becker <jlbec@...lplan.org>,
Richard Weinberger <richard@....at>,
"Darrick J. Wong" <darrick.wong@...cle.com>,
Hugh Dickins <hughd@...gle.com>, Chris Mason <clm@...com>
Subject: Re: [PATCH 3/3] ima: use fs method to read integrity data (updated
patch description)
On Sun, Sep 17, 2017 at 8:17 AM, Christoph Hellwig <hch@...radead.org> wrote:
>
> 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.
> 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?
Linus
Powered by blists - more mailing lists