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

[Alexey Gladkov <legion@kernel.org>]

On Wed, Dec 24, 2025 at 01:55:20PM +0100, Christian Brauner wrote:
> On Mon, Dec 15, 2025 at 03:58:42PM +0100, Alexey Gladkov wrote:
> > On Mon, Dec 15, 2025 at 09:46:00AM -0500, Dan Klishch wrote:
> > > On 12/15/25 5:10 AM, Alexey Gladkov wrote:
> > > > 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
> > > 
> > > This is why I have been careful not to say overlayfs. With [2] (warning:
> > > zero-shot ChatGPT output), I can do:
> > > 
> > > $ ./fuse-overlay target --source=/proc
> > > $ ls target
> > > 1   88   194   1374    889840  908552
> > > 2   90   195   1375    889987  908619
> > > 3   91   196   1379    890031  908658
> > > 4   92   203   1412    890063  908756
> > > 5   93   205   1590    890085  908804
> > > 6   94   233   1644    890139  908951
> > > 7   96   237   1802    890246  909848
> > > 8   97   239   1850    890271  909914
> > > 10  98   240   1852    894665  909924
> > > 13  99   243   1865    895854  909926
> > > 15  100  244   1888    895864  910005
> > > 16  102  246   1889    896030  acpi
> > > 17  103  262   1891    896205  asound
> > > 18  104  263   1895    896508  bus
> > > 19  105  264   1896    896544  driver
> > > 20  106  265   1899    896706  dynamic_debug
> > > <...>
> > > 
> > > [2] https://gist.github.com/DanShaders/547eeb74a90315356b98472feae47474
> > > 
> > > This requires a much more careful thought wrt magic symlinks
> > > and permission checks. The fact that I am highly unlikely to 100%
> > > correctly reimplement the checks and special behavior of procfs makes me
> > > not want to proceed with the FUSE route.
> > > 
> > > On 12/15/25 6:30 AM, Christian Brauner wrote:
> > > > The standard way of making it possible to mount procfs inside of a
> > > > container with a separate mount namespace that has a procfs inside it
> > > > with overmounted entries is to ensure that a fully-visible procfs
> > > > instance is present.
> > > 
> > > Yes, this is a solution. However, this is only marginally better than
> > > passing --privileged to the outer container (in a sense that we require
> > > outer sandbox to remove some protections for the inner sandbox to work).
> > > 
> > > > The container needs to inherit a fully-visible instance somehow if you
> > > > want nesting. Using an unprivileged LSM such as landlock to prevent any
> > > > access to the fully visible procfs instance is usually the better way.
> > > > 
> > > > My hope is that once signed bpf is more widely adopted that distros will
> > > > just start enabling blessed bpf programs that will just take on the
> > > > access protecting instead of the clumsy bind-mount protection mechanism.
> > > 
> > > These are big changes to container runtimes that are unlikely to happen
> > > soon. In contrast, the patch we are discussing will be available in 2
> > > months after the merge for me to use on ArchLinux, and in a couple more
> > > months on Ubuntu.
> > > 
> > > So, is there any way forward with the patch or should I continue trying
> > > to find a userspace solution?
> > 
> > I still consider these patches useful. I made them precisely to remove
> > some of the restrictions we have for procfs because of global files in
> > the root of this filesystem.
> > 
> > I can update and prepare a new version of patchset if Christian thinks
> > it's useful too.
> 
> Let's see it at least! No need to preemptively dismiss it. :)
> 

So what do you think about these changes?

https://lore.kernel.org/all/cover.1768295900.git.legion@kernel.org/#t

-- 
Rgrds, legion