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

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?
The other alternative is to introduce a new permission for this, but that will
deny-by-default on existing Android and allow-by-default on Fedora based
on handle-unknown until it is defined in the policy. In the case of Android, my
understanding was that kernel updates can always be coordinated with policy
updates so there is no need to worry about a new kernel breaking userspace
with old policies i.e. if and when Android ships a kernel that
includes these patches
they can also ship an updated policy that allows the new permission
where necessary
but I could be wrong.

> (I've caused stable regressions several times at this point and am
> trying to avoid causing more...)