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

[Jann Horn]

On Fri, Aug 28, 2026 at 3:10 AM Paul Moore <paul at paul-moore.com> wrote:
> On Aug 25, 2026 Jann Horn <jannh at google.com> 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>
> > Acked-by: David Hildenbrand (Arm) <david at kernel.org>
> > Acked-by: Lorenzo Stoakes (ARM) <ljs at kernel.org>
> > ---
> >  fs/proc/base.c                |  9 +++++++++
> >  include/linux/lsm_hook_defs.h |  1 +
> >  include/linux/security.h      |  6 ++++++
> >  security/security.c           | 20 ++++++++++++++++++++
> >  4 files changed, 36 insertions(+)
> >
> > diff --git a/fs/proc/base.c b/fs/proc/base.c
> > index bec6197329dc..dc6fdcb47b79 100644
> > --- a/fs/proc/base.c
> > +++ b/fs/proc/base.c
> > @@ -851,6 +851,11 @@ 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 on open bypassed because the opener used
> > +      * the same MM (introspection)?
> > +      */
> > +     bool opened_by_owner;
> >  };
> >
> >  static int mem_open(struct inode *inode, struct file *file)
> > @@ -864,12 +869,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->opened_by_owner = 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 +893,8 @@ static bool proc_mem_foll_force(struct file *file, struct mm_struct *mm)
> >               }
> >               return ptrace_active;
> >       default:
> > +             if (priv->opened_by_owner)
> > +                     return security_mem_foll_force_opened_by_owner(file->f_cred) == 0;
> >               return true;
> >       }
> >  }
>
> First things first, we've got to shorten that hook name :)  What do you
> think of security_proc_mem_foll_force()?

If we move the "opened_by_owner" part into a flag then I guess that
works... will do.

> Beyond that, we really try to avoid making LSM hook calls conditional.  It
> can limit what an LSM can enforce, it tends to be a bit more fragile, and
> it adds some unnecessary work in the case where CONFIG_SECURITY is
> disabled.  I would suggest passing 'opened_by_owner' flag as a second
> parameter to the LSM hook and calling the hook unconditionally in the
> default switch case as a replacement for the 'return true;' statement.  I
> understand it may seem a bit odd, but we try to make the LSM interface as
> generic as possible with respect to different models and this is one way

I guess I can do that, but then the question becomes, what other modes
of using the LSM hook that don't currently exist in the kernel should
I be supporting with this? I can make this a parameter, but any LSM
policy that actually uses the parameter in a different way would
probably be buggy/inconsistent, unless other new LSM hooks are added.

If your intent is to make the hook work for any /proc/$pid/mem access,
including when the caller is ptrace-attached, then I guess I have to
move around the security hook call in proc_mem_foll_force() a little
bit. I guess I'll do that in v3, though I really don't like trying to
come up with a reasonable in-kernel API contract for a scenario that
currently has zero users.

> we do that.  It also ensures we don't have to process the 'opened_by_owner'
> check in that case where the LSM is disabled.

(I don't think that's an improvement - we have to do the comparison
either way, but in the current version, we then use it to
conditionally branch to a security hook, while the v3 patch will
instead unconditionally call into the security hook.)

> >  LSM_HOOK(int, 0, capget, const struct task_struct *target, kernel_cap_t *effective,
> >        kernel_cap_t *inheritable, kernel_cap_t *permitted)
> >  LSM_HOOK(int, 0, capset, struct cred *new, const struct cred *old,
> > diff --git a/include/linux/security.h b/include/linux/security.h
> > index 153e9043058f..74eb876054b0 100644
> > --- a/include/linux/security.h
> > +++ b/include/linux/security.h
> > @@ -338,6 +338,7 @@ int security_binder_transfer_file(const struct cred *from,
> >                                 const struct cred *to, const struct file *file);
> >  int security_ptrace_access_check(struct task_struct *child, unsigned int mode);
> >  int security_ptrace_traceme(struct task_struct *parent);
> > +int security_mem_foll_force_opened_by_owner(const struct cred *subject);
> >  int security_capget(const struct task_struct *target,
> >                   kernel_cap_t *effective,
> >                   kernel_cap_t *inheritable,
> > @@ -676,6 +677,11 @@ static inline int security_ptrace_traceme(struct task_struct *parent)
> >       return cap_ptrace_traceme(parent);
> >  }
> >
> > +static inline int security_mem_foll_force_opened_by_owner(const struct cred *subject)
> > +{
> > +     return 0;
> > +}
>
> With proc_mem_foll_force() currently returning true/1 in this case,
> shouldn't the LSM hook return true/1 when disabled?

No, I have proc_mem_foll_force() doing:
"return security_mem_foll_force_opened_by_owner(file->f_cred) == 0;"

So returning 0 means "allowed", returning an error code means "denied".