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

[Christian Brauner]

On Tue, Aug 25, 2026 at 04:00:40PM +0200, Jann Horn wrote:
> On Tue, Aug 25, 2026 at 3:19 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".
> > >
> > > This causes a hole in SELinux EXECMEM enforcement, which tries to ensure
> > > that a process cannot create executable anonymous pages.
> > >
> > > PROC_MEM_FORCE_PTRACE prevents that and ensures that such FOLL_FORCE
> > > accesses are only possible when the LSM allows ptrace() attachment; but it
> > > is unclear how quickly PROC_MEM_FORCE_PTRACE can be deployed in
> > > environments running lots of third-party code, such as Android.
> > >
> > > So, introduce a new LSM hook that can forbid FOLL_FORCE specifically for
> > > such "introspective" accesses.
> > >
> > > Signed-off-by: Jann Horn <jannh at google.com>
> > > ---
> > >  fs/proc/base.c                |  6 ++++++
> > >  include/linux/lsm_hook_defs.h |  1 +
> > >  include/linux/security.h      |  6 ++++++
> > >  security/security.c           | 15 +++++++++++++++
> > >  4 files changed, 28 insertions(+)
> > >
> > > diff --git a/fs/proc/base.c b/fs/proc/base.c
> > > index bec6197329dc..3dfaef49bb70 100644
> > > --- a/fs/proc/base.c
> > > +++ b/fs/proc/base.c
> > > @@ -851,6 +851,8 @@ static int __mem_open(struct inode *inode, struct file *file, unsigned int mode)
> > >  /* private_data for proc_mem_operations */
> > >  struct mem_private {
> > >       struct mm_struct *mm;
> > > +     /* Was the ptrace access check bypassed due to introspection? */
> > > +     bool introspection;
> > >  };
> > >
> > >  static int mem_open(struct inode *inode, struct file *file)
> > > @@ -864,12 +866,14 @@ static int mem_open(struct inode *inode, struct file *file)
> > >       priv->mm = proc_mem_open(inode, PTRACE_MODE_ATTACH);
> > >       if (IS_ERR_OR_NULL(priv->mm))
> > >               return priv->mm ? PTR_ERR(priv->mm) : -ESRCH;
> > > +     priv->introspection = priv->mm == current->mm;
> > >       file->private_data = no_free_ptr(priv);
> > >       return 0;
> > >  }
> > >
> > >  static bool proc_mem_foll_force(struct file *file, struct mm_struct *mm)
> > >  {
> > > +     struct mem_private *priv = file->private_data;
> > >       struct task_struct *task;
> > >       bool ptrace_active = false;
> > >
> > > @@ -886,6 +890,8 @@ static bool proc_mem_foll_force(struct file *file, struct mm_struct *mm)
> > >               }
> > >               return ptrace_active;
> > >       default:
> > > +             if (priv->introspection)
> > > +                     return security_introspect_mem_foll_force(file->f_cred) == 0;
> >
> > Hm. Why not pass the reason to security_introspect_mem_foll_force() and
> > call it unconditionally? Similarly it could also be called for the
> > active ptracer case. Then you'd just need to pass a flag to the security
> > hook and the LSM can decide based on that.
> 
> A process which is attached as a ptracer can modify memory with (for
> example) PTRACE_POKETEXT and registers with (for example)
> PTRACE_SETREGS. LSMs that want to prevent such debugging operations
> are supposed to prevent ptrace attachment with the ptrace_access_check
> hook.

Yeah, but as I said elsewhere that is very very coarse and you can't
differentiate between the different operations performed on the other
task.

> I am just trying to plug the enforcement hole where ptrace-style
> modification of process state is possible without going through
> ptrace_access_check - which means just looking at these
> "introspection" cases.

It seems odd to just call a hook when it's introspection denied.
And if that's the case why not also have a general hook in
ptrace_may_access() itself in the introspection branch?

I would actually have use-cases for this btw.