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: Jan Kara <jack@suse.cz>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>, <mhocko@suse.cz>,
	Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: fanotify permission events on virtual filesystem
Date: Thu, 21 Mar 2019 10:36:40 +0200	[thread overview]
Message-ID: <87imwcfwtj.fsf@drapion.f-secure.com> (raw)
In-Reply-To: <CAOQ4uxjDq2ZZFwdirjrU9JG32MzQukeFr9-Ht_oQvYFo7SKQ-A@mail.gmail.com> (Amir Goldstein's message of "Wed, 20 Mar 2019 17:02:54 +0200")

Amir Goldstein <amir73il@gmail.com>:

> On Wed, Mar 20, 2019 at 4:30 PM Jan Kara <jack@suse.cz> wrote:
>> Well, I didn't mean all marks, just the permission ones. I'm not sure
>> there are apps that place permission events on /proc...
>
> Maybe not intentionally.
> I once tested a few fanotify based AntiVirus solutions.
> In some of them, setting an "Exclude path" on some mount point
> would cause mark to not be set on that path, but for one in particular,
> the mark was still being set on the mount so path pattern filtering was
> done after receiving the events.
> I did not check whether /proc was blacklisted out of the box or if it
> could be marked/excluded from scan.
> IMO, assuming that all AntiVirus vendors blacklist all virtual filesystems
> is an assumption that we need to validate.
> [CC Marko from F-Secure for commenting on the above.]

Yeah, we have learned by experimentation to not mark some file systems.

(Also, inspecting some /proc files *during* OPEN_PERM processing of a
regular file can lead to deadlocks.)


Marko

  reply	other threads:[~2019-03-21  8:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-20 13:16 fanotify permission events on virtual filesystem Jan Kara
2019-03-20 13:46 ` Amir Goldstein
2019-03-20 14:30   ` Jan Kara
2019-03-20 15:02     ` Amir Goldstein
2019-03-21  8:36       ` Marko Rauhamaa [this message]
2019-04-01 17:26       ` Jan Kara

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=87imwcfwtj.fsf@drapion.f-secure.com \
    --to=marko.rauhamaa@f-secure.com \
    --cc=amir73il@gmail.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mhocko@suse.cz \
    --cc=viro@zeniv.linux.org.uk \
    /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.