Re: [RFC PATCH] ima: force the re-evaluation of files on untrusted file systems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Feb 5, 2018 at 5:21 PM, Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote:
> On Mon, 2018-02-05 at 17:12 +0100, Miklos Szeredi wrote:
>> On Mon, Feb 5, 2018 at 4:50 PM, James Bottomley
>> <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
>> > On Mon, 2018-02-05 at 08:40 -0500, Mimi Zohar wrote:
>> >> On filesystems, such as fuse or remote filesystems, that we can not
>> >> detect or rely on the filesystem to tell us when a file has changed,
>> >> always re-measure, re-appraise, and/or re-audit the file.
>> >
>> > Using the presence or absence of d_revalidate isn't definitive for
>> > uncacheable appraisals: all stacked filesystems have to implement
>> > d_revalidate just in case the underlying has it, but it doesn't mean
>> > their appraisals can't be cached if they're fully built on top of
>> > traditional filesystems (like they are in the Docker/OCI use case).  I
>> > think the original flag approach is better.  The only thing stackable
>> > filesystems argues for is that for them it should probably be a
>> > superblock flag so it can be per-mount point (depending on overlay
>> > composition).
>> >
>> > d_revalidate() also strikes me as wrong from the semantic point of
>> > view: it's about whether the path name to inode cache needs re-
>> > evaluating not whether the underlying inode could change arbitrarily.
>> >  These are definitely related but not necessarily equivalent concepts.
>>
>> True.  A more precise indication is whether cache pages have been
>> invalidated for a certain inode.   Can we used that?  I.e.
>> invalidate_inode_pages*() calls down into IMA or sets a flags or
>> whatever to indicate that the file contents might have changed.
>
> I don't think that works for the FUSE use case.

Okay, it's true that cache invalidation is just a hint about file
contents changing.  The file contents could change without cache
invalidation if userspace filesystem is buggy or malicious.

Thanks,
Miklos



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux