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: <aT7ohARHhPEmFlW9@example.org>
Date: Sun, 14 Dec 2025 17:40:36 +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 Sat, Dec 13, 2025 at 01:00:38PM -0500, Dan Klishch wrote:
> > It is much easier to implement file access
> > restrictions in procfs using an ebpf controller.
> 
> But if we already have a masked /proc from podman/docker/user who
> decided to run `mount --bind /dev/null /proc/smth`, the sandbox will
> not have a choice other than to bail out.

I misunderstood you. I thought you were writing your own container
implementation.

Yes, if you want a nested container inside docker/podman, then file
overmount technique is already used there.

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.

> 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.

-- 
Rgrds, legion