linux-kernel - Re: [PATCH] overlayfs: port all superblock creation logging to fsopen logs

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: <CAOQ4uxj+gAtM6cY_aEmM7TAqLor7498f0FO3eTek_NpUXUKNaw@mail.gmail.com>
Date: Wed, 6 Nov 2024 12:04:27 +0100
From: Amir Goldstein <amir73il@...il.com>
To: Christian Brauner <brauner@...nel.org>, Miklos Szeredi <miklos@...redi.hu>
Cc: Aleksa Sarai <cyphar@...har.com>, Jan Kara <jack@...e.cz>, linux-unionfs@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Karel Zak <kzak@...hat.com>, 
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH] overlayfs: port all superblock creation logging to fsopen logs

[Fixed address of linux-fsdevel]

On Wed, Nov 6, 2024 at 12:00 PM Amir Goldstein <amir73il@...il.com> wrote:
>
> On Wed, Nov 6, 2024 at 10:59 AM Christian Brauner <brauner@...nel.org> wrote:
> >
> > On Wed, Nov 06, 2024 at 02:09:58PM +1100, Aleksa Sarai wrote:
> > > overlayfs helpfully provides a lot of of information when setting up a
> > > mount, but unfortunately when using the fsopen(2) API, a lot of this
> > > information is mixed in with the general kernel log.
> > >
> > > In addition, some of the logs can become a source of spam if programs
> > > are creating many internal overlayfs mounts (in runc we use an internal
> > > overlayfs mount to protect the runc binary against container breakout
> > > attacks like CVE-2019-5736, and xino_auto=on caused a lot of spam in
> > > dmesg because we didn't explicitly disable xino[1]).
> > >
> > > By logging to the fs_context, userspace can get more accurate
> > > information when using fsopen(2) and there is less dmesg spam for
> > > systems where a lot of programs are using fsopen("overlay"). Legacy
> > > mount(2) users will still see the same errors in dmesg as they did
> > > before (though the prefix of the log messages will now be "overlay"
> > > rather than "overlayfs").
>
> I am not sure about the level of risk in this format change.
> Miklos, WDYT?
>
> > >
> > > [1]: https://bbs.archlinux.org/viewtopic.php?pid=2206551
> > >
> > > Signed-off-by: Aleksa Sarai <cyphar@...har.com>
> > > ---
> >
> > To me this sounds inherently useful! So I'm all for it.
> >
>
> [CC: Karel]
>
> I am quite concerned about this.
> I have a memory that Christian suggested to make this change back in the
> original conversion to new mount API, but back then mount tool
> did not print out the errors to users properly and even if it does
> print out errors,
> some script could very well be ignoring them.
>
> My strong feeling is that suppressing legacy errors to kmsg should be opt-in
> via the new mount API and that it should not be the default for libmount.
> IMO, it is certainly NOT enough that new mount API is used by userspace
> as an indication for the kernel to suppress errors to kmsg.
> I have no problem with reporting errors to both userspace and kmsg
> without opt-in from usersapce.
>
> Furthermore, looking at the existing invalfc() calls in overlayfs, I see that
> a few legacy pr_err() were converted to invalfc() with this commit
> (signed off by myself):
> 819829f0319a ovl: refactor layer parsing helpers
>
> I am not really sure if the discussion about suppressing the kmsg errors was
> resolved or dismissed or maybe it only happened in my head??
>
> Thanks,
> Amir.