All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.