linux-kernel - Re: [RFC 2/2] fanotify: emit FAN_MODIFY

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: <CAOQ4uxiDmujrY0eRdOL5GLfEtRRg-W2x3vRja59Z=YVKA=BrMA@mail.gmail.com>
Date:   Wed, 15 Mar 2017 16:44:58 +0200
From:   Amir Goldstein <amir73il@...il.com>
To:     Jan Kara <jack@...e.cz>
Cc:     Marko Rauhamaa <marko.rauhamaa@...ecure.com>,
        Filip Štědronský <r.lkml@...narg.cz>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Wed, Mar 15, 2017 at 3:39 PM, Jan Kara <jack@...e.cz> wrote:
> On Wed 15-03-17 10:19:52, Marko Rauhamaa wrote:
>> Filip Štědronský <r.lkml@...narg.cz>:
>>
>> > there are basically two classes of uses for a fantotify-like
>> > interface:
>> >
>> > (1) Keeping an up-to-date representation of the file system. For this,
>> >     superblock watches are clearly what you want.
>> >
>> >     [...]
>> >
>> >     All those factors speak greatly in favour of superblock
>> >     watches.
>> >
>> > (2) Tracking filesystem *activity*. Now you are not building
>> >     an image of current filesystem state but rather a log of what
>> >     happened. Perhaps you are also interested in who
>> >     (user/process/...) did what. Permission events also fit mostly in
>> >     this category.
>> >
>> >     For those it *might* make sense to have mount-scoped watches, for
>> >     example if you want to monitor only one container or a subset of
>> >     processes.
>> >
>> > We both concentrate on the first but we shouldn't forget about the
>> > second, which was one of the original motivations for fanotify.
>>
>> My (employer's) needs are centered around (2). We definitely crave
>> permission events with a filesystem scope. At the moment, you can avoid
>> permission checks with a simple unshare command (<URL:
>> https://lkml.org/lkml/2016/12/21/144>).
>
> Yes, that is bad.
>
>> So I must be able to see everything that is happening in my universe. It
>> might also be useful to monitor a subuniverse of mine, but the former
>> need is critical at the moment.
>
> So I understand your need. However with superblock watches I'm still
> concerned that the process would be able to see too much. E.g. if it is
> restricted to see only some subtree of a filesystem (by bind mounts &
> namespaces), it should not be able to see events on the same filesystem
> outside of that subtree. I have not found a good solution for that yet.
>

See the last patch in my series. The cherry on the top ;-)

commit 5e3b5bd943991cdf5b72745c1e24833bc998b7ed
Author: Amir Goldstein <amir73il@...il.com>
Date:   Sun Dec 18 11:25:55 2016 +0200

    fanotify: filter events by root mark mount point

    When adding a super block root watch from a mount point that is not mounted
    on the root of the file system, filter out events on file system objects
    that happen outside this mount point directory (on non decendant objects).

    This is not like FAN_MARK_MOUNT which filters only events that happened
    on the mount of the mark. All events on file system objects are reported
    as long as these objects are accessible from the mark mount point.

    Signed-off-by: Amir Goldstein <amir73il@...il.com>

 fs/notify/fanotify/fanotify.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

Our use case is monitoring a large directory tree, not the entire file system.

I used a simple check in should_send_event()

+       /*
+        * Only interesetd in dentry events visible from the mount
+        * from which the root watch was added
+        */
+       if (mark_mnt && mark_mnt->mnt_root != dentry &&
+           d_ancestor(mark_mnt->mnt_root, dentry) == NULL)
+               return false;
+

This does not cover the case of events on objects that are hidden
under another mount in my mount namespace, but it covers the
simple case of bind mount.

Note that 'mark_mnt' does NOT stand for the vfs_mark mount,
because root watch is an inode_mark (on the root inode).
It stands for the mount from which the root watch was added.
Same mount that is used to construct the event->fd for all
the dentry events.

This scheme does NOT allow multiple root watches with
different mount point filter on the same group.
Every group can have just one root watch per sb with a single
mount filter.

Amir.