[PATCH 2/3] proc: query LSMs for introspective mem access (if PROC_MEM_FORCE_ALWAYS)

[Christian Brauner]

On Tue, Aug 25, 2026 at 03:46:50PM +0200, Jann Horn wrote:
> On Tue, Aug 25, 2026 at 3:13 PM Christian Brauner <brauner at kernel.org> wrote:
> > On Tue, Aug 18, 2026 at 09:51:06PM +0200, Jann Horn wrote:
> > > If the system is running with PROC_MEM_FORCE_ALWAYS, LSMs currently have no
> > > good opportunity to block a process from overwriting read-only code in its
> > > own address space through FOLL_FORCE writes via /proc/self/mem.
> > > The security_ptrace_access_check() LSM hook is bypassed when a process
> > > opens /proc/self/mem because this is considered "introspection".
> >
> > Useful. I ran into this issue just yesterday in:
> >
> > https://github.com/systemd/systemd/pull/43511
> >
> > Btw, it's kinda annoying that PTRACE_POKE{TEXT,DATA} still allows foll
> > force writes even if PROC_MEM_FORCE_NEVER is enabled. So ideally there'd
> > also be a hook for that option.
> 
> You need either /proc/$pid/mem or PTRACE_POKETEXT for installing
> software breakpoints. I think if you want to completely block

This won't be enabled for general-purpose systems. But for a lot of
other systems with a lot stricter requirements this is very useful. And
you can always allow a mode where you intentionally degrade to an
audited "debug" mode where you can turn of the restrictions. Which btw,
isn't possible with seccomp.

> FOLL_FORCE through ptrace, you're probably in a scenario where ptrace
> should either be blocked completely, or at least restricted to
> mostly-read-only operations?

Yes but the list of ptrace() options is prctl()-like. They even have
interactions. Also seccomp isn't necessarily the right tool for this
because it doesn't allow dynamic policies. That would be lsm territory.

> 
> > The other thing - though not directly FOLL_FORCE related - is that
> > process_vm_writev() isn't subject to any security restrictions other
> > than seccomp filtering either.
> 
> It does go through mm_access() and ptrace_may_access() unless the
> access is same-MM, so it can be blocked by LSMs like Yama.

I think ptrace_may_access() is way to coarse to be really useful. It's a
very frustrating tool. It's easy to use because everyone knows "you need
to access properties of another task, ptrace_may_access() is your guy".
But it prevents better policies. TL;DR you never know _why_ you were
called specifically.