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: <871stzc5p3.fsf@drapion.f-secure.com>
Date:   Wed, 15 Mar 2017 10:19:52 +0200
From:   Marko Rauhamaa <marko.rauhamaa@...ecure.com>
To:     Filip Štědronský <r.lkml@...narg.cz>
CC:     Amir Goldstein <amir73il@...il.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Jan Kara <jack@...e.cz>,
        Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

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>).

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.

As for "who (user/process/...) did what", the fanotify API is flawed in
that we don't have a CLOSE_WRITE_PERM event. The hit-and-run process is
long gone by the time we receive the event. That's more of a rule than
an exception.

Marko