linux-kernel - Re: [RESEND PATCH v6 0/5] proc: subset=pid: Relax check of mount visibility

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: <aT_elfmyOaWuJRjW@example.org>
Date: Mon, 15 Dec 2025 11:10:29 +0100
From: Alexey Gladkov <legion@...nel.org>
To: Dan Klishch <danilklishch@...il.com>
Cc: containers@...ts.linux-foundation.org, ebiederm@...ssion.com,
	keescook@...omium.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, viro@...iv.linux.org.uk
Subject: Re: [RESEND PATCH v6 0/5] proc: subset=pid: Relax check of mount
 visibility

On Sun, Dec 14, 2025 at 01:02:54PM -0500, Dan Klishch wrote:
> On 12/14/25 11:40 AM, Alexey Gladkov wrote:
> > But then, if I understand you correctly, this patch will not be enough
> > for you. procfs with subset=pid will not allow you to have /proc/meminfo,
> > /proc/cpuinfo, etc.
> 
> Hmm, I didn't think of this. sunwalker-box only exposes cpuinfo and PID
> tree to the sandboxed programs (empirically, this is enough for most of
> programs you want sandboxing for). With that in mind, this patch and a
> FUSE providing an overlay with cpuinfo / seccomp intercepting opens of
> /proc/cpuinfo / a small kernel patch with a new mount option for procfs
> to expose more static files still look like a clean solution to me.

I don't think you'll be able to do that. procfs doesn't allow itself to
be overlayed [1]. What should block mounting overlayfs and fuse on top
of procfs.

[1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/proc/root.c#n274

> >> Also, correct me if I am wrong, installing ebpf controller requires
> >> CAP_BPF in initial userns, so rootless podman will not be able to mask
> >> /proc "properly" even if someone sends a patch switching it to ebpf.
> > 
> > You can turn on /proc/sys/kernel/unprivileged_bpf_disabled.
> 
> $ cat /proc/sys/kernel/unprivileged_bpf_disabled
> 0
> $ unshare -pfr --mount-proc
> $ ./proc-controller -p deny /proc/cpuinfo
> libbpf: prog 'proc_access_restrict': BPF program load failed: Operation not permitted
> libbpf: prog 'proc_access_restrict': failed to load: -1
> libbpf: failed to load object './proc-controller.bpf.o'
> proc-controller: ERROR: loading BPF object file failed
> 
> I think only packet filters are allowed to be installed by non-root.

I probably forgot about that. I wrote this code a long time ago, and
to be honest, I forgot whether it can be used for rootless.

-- 
Rgrds, legion