linux-kernel - Re: [PATCH 0/2] acct: don't allow access to internal filesystems

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: <c780964d17b908846f07d01f4020be7bc784ec8b.camel@kernel.org>
Date: Tue, 11 Feb 2025 13:56:41 -0500
From: Jeff Layton <jlayton@...nel.org>
To: Christian Brauner <brauner@...nel.org>, Zicheng Qu
 <quzicheng@...wei.com>,  Linus Torvalds <torvalds@...ux-foundation.org>
Cc: axboe@...nel.dk, joel.granados@...nel.org, tglx@...utronix.de, 
	viro@...iv.linux.org.uk, hch@....de, len.brown@...el.com, pavel@....cz, 
	pengfei.xu@...el.com, rafael@...nel.org, tanghui20@...wei.com, 
	zhangqiao22@...wei.com, judy.chenhui@...wei.com,
 linux-kernel@...r.kernel.org, 	linux-fsdevel@...r.kernel.org,
 syzkaller-bugs@...glegroups.com, 	linux-pm@...r.kernel.org,
 stable@...r.kernel.org
Subject: Re: [PATCH 0/2] acct: don't allow access to internal filesystems

On Tue, 2025-02-11 at 18:15 +0100, Christian Brauner wrote:
> In [1] it was reported that the acct(2) system call can be used to
> trigger a NULL deref in cases where it is set to write to a file that
> triggers an internal lookup.
> 
> This can e.g., happen when pointing acct(2) to /sys/power/resume. At the
> point the where the write to this file happens the calling task has
> already exited and called exit_fs() but an internal lookup might be
> triggered through lookup_bdev(). This may trigger a NULL-deref
> when accessing current->fs.
> 
> This series does two things:
> 
> - Reorganize the code so that the the final write happens from the
>   workqueue but with the caller's credentials. This preserves the
>   (strange) permission model and has almost no regression risk.
> 
> - Block access to kernel internal filesystems as well as procfs and
>   sysfs in the first place.
> 
> This api should stop to exist imho.
> 

I wonder who uses it these days, and what would we suggest they replace
it with? Maybe syscall auditing?

config BSD_PROCESS_ACCT
        bool "BSD Process Accounting"
        depends on MULTIUSER
        help
          If you say Y here, a user level program will be able to instruct the
          kernel (via a special system call) to write process accounting
          information to a file: whenever a process exits, information about
          that process will be appended to the file by the kernel.  The
          information includes things such as creation time, owning user,
          command name, memory usage, controlling terminal etc. (the complete
          list is in the struct acct in <file:include/linux/acct.h>).  It is
          up to the user level program to do useful things with this
          information.  This is generally a good idea, so say Y.

Maybe at least time to replace that last sentence and make this default
to 'n'?

> Link: https://lore.kernel.org/r/20250127091811.3183623-1-quzicheng@huawei.com [1]
> 
> Signed-off-by: Christian Brauner <brauner@...nel.org>
> ---
> Christian Brauner (2):
>       acct: perform last write from workqueue
>       acct: block access to kernel internal filesystems
> 
>  kernel/acct.c | 134 ++++++++++++++++++++++++++++++++++++----------------------
>  1 file changed, 84 insertions(+), 50 deletions(-)
> ---
> base-commit: af69e27b3c8240f7889b6c457d71084458984d8e
> change-id: 20250211-work-acct-a6d8e92a5fe0
> 

-- 
Jeff Layton <jlayton@...nel.org>