On Mon, Dec 11, 2017 at 08:12:58AM -0500, Mimi Zohar wrote: > On Mon, 2017-12-11 at 09:07 +1100, James Morris wrote: > > On Fri, 8 Dec 2017, Mimi Zohar wrote: > > > > > There are times instead of relying on previously cached status > > > information we want to force the file to be re-measured, re-appraised, > > > and re-audited. > > > > Can you give an example of when this would be needed? > > Up to Sascha Hauer's patch "ima: Use i_version only when filesystem > supports it", which is queued to be upstreamed, the cached flags are > reset only if the i_version changed, causing the file to be re- > evaluated. After that patch, the cached flags are also reset if > i_version is not enabled. > > That leaves the case where i_version is enabled for the filesystem, > but the local kernel is not responsible for updating it. This patch > is mainly for filesystems, where we can't trust the filesystem > properly increments i_version. > > Eric/Seth, with Sasha's patch is this patch still needed for fuse > filesystems? I think so. With fuse the file data is being generated by a userspace process, so the concern is that the process could change the file data without the kernel's knowledge and IMA would still use the cached result. And fuse is often mounted by unprivileged users. It looks like Sascha's patch only addresses the issue for file data changes that happen via the kernel and not for data which could change outside of the kernel's knowledge. Seth
