From: Christian Brauner <email@example.com> To: Jan Kara <firstname.lastname@example.org> Cc: Amir Goldstein <email@example.com>, linux-fsdevel <firstname.lastname@example.org>, Miklos Szeredi <email@example.com> Subject: Re: [RFC][PATCH] fanotify: introduce filesystem view mark Date: Wed, 12 May 2021 18:15:42 +0200 Message-ID: <20210512161542.asyjkxflkzfvgp3s@wittgenstein> (raw) In-Reply-To: <20210512133415.GC2734@quack2.suse.cz> On Wed, May 12, 2021 at 03:34:15PM +0200, Jan Kara wrote: > On Wed 12-05-21 15:07:05, Christian Brauner wrote: > > On Mon, May 10, 2021 at 06:08:31PM +0300, Amir Goldstein wrote: > > > > > > OK, so this feature would effectively allow sb-wide watching of events that > > > > > > are generated from within the container (or its descendants). That sounds > > > > > > useful. Just one question: If there's some part of a filesystem, that is > > > > > > accesible by multiple containers (and thus multiple namespaces), or if > > > > > > there's some change done to the filesystem say by container management SW, > > > > > > then event for this change won't be visible inside the container (despite > > > > > > that the fs change itself will be visible). > > > > > > > > > > That is correct. > > > > > FYI, a privileged user can already mount an overlayfs in order to indirectly > > > > > open and write to a file. > > > > > > > > > > Because overlayfs opens the underlying file FMODE_NONOTIFY this will > > > > > hide OPEN/ACCESS/MODIFY/CLOSE events also for inode/sb marks. > > > > > Since 459c7c565ac3 ("ovl: unprivieged mounts"), so can unprivileged users. > > > > > > > > > > I wonder if that is a problem that we need to fix... > > > > > > > > I assume you are speaking of the filesystem that is absorbing the changes? > > > > AFAIU usually you are not supposed to access that filesystem alone but > > > > always access it only through overlayfs and in that case you won't see the > > > > problem? > > > > > > > > > > Yes I am talking about the "backend" store for overlayfs. > > > Normally, that would be a subtree where changes are not expected > > > except through overlayfs and indeed it is documented that: > > > "If the underlying filesystem is changed, the behavior of the overlay > > > is undefined, though it will not result in a crash or deadlock." > > > Not reporting events falls well under "undefined". > > > > > > But that is not the problem. > > > The problem is that if user A is watching a directory D for changes, then > > > an adversary user B which has read/write access to D can: > > > - Clone a userns wherein user B id is 0 > > > - Mount a private overlayfs instance using D as upperdir > > > - Open file in D indirectly via private overlayfs and edit it > > > > > > So it does not require any special privileges to circumvent generating > > > events. Unless I am missing something. > > > > No, I think you're right. That should work. I don't think that's > > necessarily a problem though. It's a bit unexpected and slightly > > unpleasant but it's documented already and it's not a security issue > > afaict. > > fanotify(7) is used in applications (such as virus scanners or anti-malware > products) where they expect to see all filesystem changes. There are > products which implement access mediation policy based on fanotify > permission events. So a way for unpriviledged application to escape > notification is a "security" issue (not a kernel one but it defeats > protections userspace implements). Ah, good point. I assumed since this has always been the case although restricted to privileged users on the host, i.e. creating an overlayfs mount would always have that affect iiuc.
next prev parent reply index Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-11-09 18:00 Amir Goldstein 2020-11-10 5:07 ` Amir Goldstein 2020-11-17 7:09 ` [fanotify] a23a7dc576: unixbench.score -3.7% regression kernel test robot 2020-11-24 13:49 ` [RFC][PATCH] fanotify: introduce filesystem view mark Jan Kara 2020-11-24 14:47 ` Amir Goldstein 2020-11-25 11:01 ` Jan Kara 2020-11-25 12:34 ` Amir Goldstein 2020-11-26 11:10 ` Jan Kara 2020-11-26 11:50 ` Amir Goldstein 2020-11-26 3:42 ` Amir Goldstein 2020-11-26 11:17 ` Jan Kara 2021-04-28 18:28 ` Amir Goldstein 2021-05-03 16:53 ` Jan Kara 2021-05-03 18:44 ` Amir Goldstein 2021-05-05 12:28 ` Jan Kara 2021-05-05 14:24 ` Christian Brauner 2021-05-05 14:42 ` Amir Goldstein 2021-05-05 14:56 ` Christian Brauner 2021-05-10 10:13 ` Jan Kara 2021-05-10 11:37 ` Amir Goldstein 2021-05-10 14:21 ` Jan Kara 2021-05-10 15:08 ` Amir Goldstein 2021-05-10 15:27 ` Jan Kara 2021-05-12 13:07 ` Christian Brauner 2021-05-12 13:34 ` Jan Kara 2021-05-12 16:15 ` Christian Brauner [this message] 2021-05-12 15:26 ` Christian Brauner 2021-05-13 10:55 ` Jan Kara 2021-05-14 13:56 ` Christian Brauner 2021-05-15 14:28 ` Amir Goldstein 2021-05-17 9:09 ` Jan Kara 2021-05-17 12:45 ` Amir Goldstein 2021-05-17 13:07 ` Jan Kara 2021-05-18 10:11 ` Christian Brauner 2021-05-18 16:02 ` Amir Goldstein 2021-05-19 9:31 ` Christian Brauner 2021-05-12 16:11 ` Christian Brauner 2021-05-05 13:25 ` Christian Brauner
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=20210512161542.asyjkxflkzfvgp3s@wittgenstein \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.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
Linux-Fsdevel Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-fsdevel/0 linux-fsdevel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-fsdevel linux-fsdevel/ https://lore.kernel.org/linux-fsdevel \ email@example.com public-inbox-index linux-fsdevel Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-fsdevel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git