On Tue, 16 Apr 2024 at 21:06, Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote:
>
> On Tue, 2024-04-16 at 16:46 +0200, Miklos Szeredi wrote:
> > On Tue, 16 Apr 2024 at 14:18, Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote:
> > > Originally there was a single measureent unless the filesystem was mounted with
> > > SB_I_VERSION. With commit a2a2c3c8580a ("ima: Use i_version only when
> > > filesystem supports it") this changed to always re-measure the file if the
> > > filesystem wasn't mounted with SB_I_VERSION.
> >
> > Does the i_version get stored and compared only while the inode is in memory?
> >
> > In that case I think it should be possible to support a version number
> > for the overlay inode.
>
> i_version was insufficient to detect a file change for overlay. Commit
> b836c4d29f27 ("ima: detect changes to the backing overlay") also compares the
> i_ino and s_dev as well. Refer to
> https://lore.kernel.org/lkml/20231025143906.133218-1-zohar@xxxxxxxxxxxxx/.
Which is rather ad-hoc.
I'm talking about returning something in overlay i_version, which
really indicates the version of the overlay file calculated from the
i_version of the underlying files. The only issue is making this
i_version persistent, AFAICS. If that's not needed than the overlayfs
specific logic in IMA could be moved into overlayfs, where it belongs.
> Here in this patch set we need to detect IMA read/write violations, based on the
> i_readcount/i_writecount. If an overlay file is opened for read, but the
> backing file is already opened for write, the file measurement is
> meaningless. An "open-writers" violation needs to be generated; and the IMA
> measurement list needs to be invalidated.
If there's no other way, then let's implement an API to query the
writecount that can take overlayfs into account. This is for the VFS
and/or overlayfs to calculate, not for IMA.
Thanks,
Miklos
