linux-kernel - Re: fsnotify_mark

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOQ4uxgu=vtHtYcvkFkaX_M3yT40VWnatNtrAk49-O94gpusNQ@mail.gmail.com>
Date:   Fri, 2 Dec 2016 13:41:17 +0200
From:   Amir Goldstein <amir73il@...il.com>
To:     Jan Kara <jack@...e.cz>
Cc:     Miklos Szeredi <miklos@...redi.hu>, Eric Paris <eparis@...hat.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: fsnotify_mark_srcu wtf?

On Fri, Dec 2, 2016 at 12:48 PM, Jan Kara <jack@...e.cz> wrote:
> On Fri 02-12-16 09:26:51, Miklos Szeredi wrote:
...
>>
>> Hmm, how about this: when removing mark from inode, drop refcount.  If
>> refcount is zero can remove from list.  Otherwise mark the mark "dead"
>> and leave it on the list.
>>
>> And fsnotify can just skip dead marks.
>
> I had this idea as well and when trying to implement this, I've stumbled
> over some problems. I think the biggest problem was that destruction of a
> notification mark is relatively complex operation (doing iput() for
> example) and quite a few places dropping mark references are in a context
> where this can cause problems. Also I don't want to defer iput() to a
> workqueue as that will have unexpected consequences such as unlinked
> watched inode lingering in the system (possibly colliding with umount
> etc.).
>

I am wondering out loud if we are trying to solve a real problem or a made
up test case. I wonder if Miklos' test program truly represents the original
bug report. I am asking because fanotify permission events are usually
associated with system security software and it usually makes sense on
a vfsmount_mark and not an inode_mark.

Maybe the break even solution is not to split destroy lists per group priority,
but to split destroy lists by inode marks and vfsmount marks
and also keep 2 separate lists per group.

I am only asking this because you mentioned iput as a thorn in the solution.
Since vfsmount mark does not pin the mount, nor hold an elevated reference,
perhaps dealing with simpler destruction of vfsmount marks can solve the
problem for "rogue fanotify permission mount watch" and maybe that is
enough for all practical matters?

Amir.