Re: [PATCH 3/3] selinux: require EXECMEM or PTRACE for FOLL_FORCE introspection
Jann Horn <[email protected]>
| Newsgroups | org.kernel.vger.linux-security-module,org.kernel.vger.linux-fsdevel,org.kernel.vger.selinux,org.kvack.linux-mm |
|---|---|
| Message-ID | <CAG48ez3h2Gft4onQ8AgBmf8gHrF26YqTinajuBysNPkUKaTBoA@mail.gmail.com> |
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've caused stable regressions several times at this point and am trying to avoid causing more...)