From: Marko Rauhamaa <marko.rauhamaa@f-secure.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [RFC][PATCH 0/7] fanotify: add support for more events
Date: Fri, 14 Oct 2016 11:28:07 +0300 [thread overview]
Message-ID: <87d1j3mj1k.fsf@drapion.f-secure.com> (raw)
In-Reply-To: <CAOQ4uxhxbhK5j=EKYNgeQuSDCT+PUM6Xf0w1c9ApK96nikLT9A@mail.gmail.com> (Amir Goldstein's message of "Thu, 13 Oct 2016 21:42:10 +0300")
Amir Goldstein <amir73il@gmail.com>:
> On Thu, Oct 13, 2016 at 8:35 PM, Marko Rauhamaa
>> My employer certainly is in need of monitoring a whole filesystem. We
>> have noticed that namespaces evade monitoring via FAN_MARK_MOUNT. I
>> was thinking something like a FAN_MARK_FILESYSTEM would be needed.
>
> [...]
>
> I keep hearing about people that wanted that feature, but those people will
> need to come forward and voice their use cases.
Well, F-Secure's Linux Security product monitors files to detect
malware. Files are analyzed for viruses and unexpected modifications to
system files are flagged.
Other fanotify deficiencies include:
* the offending process can die without leaving a trace because
FAN_CLOSE_WRITE events do not block (instead of blocking, it would be
enough for the /proc/$PID directory to stay available while the
related fanotify fd is open)
* the (e)uid and (e)gid of the offending process are not conveyed in
the fanotify event
* the FAN_OPEN_PERM event does not carry the mode so write access
cannot be denied
* there is no (PERM or non-PERM) event generated by the first
modification (FAN_MODIFY generates a flurry of events;
FAN_CLOSE_WRITE does not get generated unless the file is closed)
Marko
next prev parent reply other threads:[~2016-10-14 8:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-13 17:35 [RFC][PATCH 0/7] fanotify: add support for more events Marko Rauhamaa
2016-10-13 18:42 ` Amir Goldstein
2016-10-14 8:28 ` Marko Rauhamaa [this message]
2016-10-15 15:23 ` Amir Goldstein
2016-10-17 8:43 ` Marko Rauhamaa
2016-12-09 9:14 ` Amir Goldstein
2016-12-09 13:16 ` Marko Rauhamaa
-- strict thread matches above, loose matches on Subject: below --
2016-10-10 19:12 Amir Goldstein
2016-10-11 7:00 ` Amir Goldstein
2016-10-11 11:32 ` Jan Kara
2016-10-12 11:49 ` Amir Goldstein
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d1j3mj1k.fsf@drapion.f-secure.com \
--to=marko.rauhamaa@f-secure.com \
--cc=amir73il@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.