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

On Sat, Dec 13, 2025 at 12:06:38AM -0500, Dan Klishch wrote:
> Hello Alexey,
> 
> Would it be possible to revive this patch series?
> 
> I wanted to add an additional downstream use case that would benefit
> from this work. In particular, I am trying to run the sandbox
> sunwalker-box [1] without root privileges and/or inside a container.
> 
> The sandbox aims to prevent cross-run communication via side channels,
> and PID allocation is one such channel. Therefore, it creates a new PID
> namespace and mounts the corresponding procfs instance inside of the
> sandbox. This currently works without a real root when procfs is fully
> accessible, but obviously fails otherwise.
> 
> Thanks,
> Dan Klishch
> 
> [1] https://github.com/purplesyringa/sunwalker-box/
> 

Overmounting "dangerous" files in procfs is an incorrect and potentially
dangerous practice. I know that many programs (docker, podman, etc.) use
this method, but it is not the correct way to isolate dangerous files in
procfs.

In particular, this is one of the reasons why this patchset was abandoned.

It is quite difficult to implement these checks in procfs correctly and
not break anything. It is much easier to implement file access
restrictions in procfs using an ebpf controller. Some time ago, I tried to
implement such a controller [1], and it seemed to me that it was much
easier than adding complex checks to the kernel.

If I'm wrong and missing a use case, let me know and we can go back to
the patches.

[1] https://github.com/legionus/proc-bpf-controller

-- 
Rgrds, legion


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ