Re: [PATCH 3/3] selinux: require EXECMEM or PTRACE for FOLL_FORCE introspection

On Fri, Aug 21, 2026 at 3:52 PM Stephen Smalley
<[email protected]> wrote:
> On Thu, Aug 20, 2026 at 11:23 AM Jann Horn <[email protected]> wrote:
> > On Wed, Aug 19, 2026 at 4:54 PM Stephen Smalley
> > <[email protected]> wrote:
> > > On Tue, Aug 18, 2026 at 3:51 PM Jann Horn <[email protected]> wrote:
> > > >
> > > > On systems configured with PROC_MEM_FORCE_ALWAYS, ensure that a process can
> > > > only create anonymous executable memory via /proc/self/mem if it has one
> > > > of:
> > > >
> > > >  - EXECMEM (like for other methods of creating anonymous executable pages)
> > > >  - PTRACE (like when using /proc/$pid/mem of another process)
> > >
> > > Allowing it if _either_ permission is allowed is unusual in SELinux
> > > and seems prone to errors.
> > > Is there a reason to not just require PTRACE always?
> >
> > Hmm, that might work.
> >
> > My two concerns about that approach are:
> >
> > 1. This is an operation where a process acts on itself, while PTRACE
> > is normally for acting on another process. It feels to me like those
> > are different types of privilege.
> > 2. I feel like blocking this operation even for a process with EXECMEM
> > privilege increases the risk of breaking existing configurations.
> >
> > I think if we want to gate it on PTRACE, we might need to put this
> > behind a policy capability and let policy authors figure this out?
> > But I'm no expert on how new security hooks are normally added, or
> > what SELinux policies outside Android look like, so if you think it
> > would be fine to just check for PTRACE, I'd be happy to go with that.
>
> I don't think a new policy capability is necessary here. Is there any legitimate
> user of this capability that wouldn't already have ptrace permission?

I do not know of one.
I was thinking that it is theoretically possible that some program out
there uses /proc/self/mem to patch its own code (similarly to how the
Linux kernel has Static Keys) or to inspect its own execute-only,
non-readable code (which I think would also require FOLL_FORCE); but
I'm not aware of any concrete cases that do that.

So I guess if nobody else has an opinion on this, I'll change this to
only check for PTRACE as you suggested.