diff options
| author | Jann Horn <jannh@google.com> | 2026-09-07 23:00:17 +0200 |
|---|---|---|
| committer | Christian Brauner <brauner@kernel.org> | 2026-09-10 09:48:17 +0200 |
| commit | 9f90f96af73d5fd2dee0a0459a89ac467f3ecf5e (patch) | |
| tree | e0a387569537df91a0ea964d2dc27e52957e12ae /tools/lib/python | |
| parent | d5662602d178c6090b2e3887029f91a7e1be3a0f (diff) | |
| download | linux-next-9f90f96af73d5fd2dee0a0459a89ac467f3ecf5e.tar.gz linux-next-9f90f96af73d5fd2dee0a0459a89ac467f3ecf5e.zip | |
proc: query LSMs for introspective mem access (if PROC_MEM_FORCE_ALWAYS)
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.
Acked-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Signed-off-by: Jann Horn <jannh@google.com>
Link: https://patch.msgid.link/20260907-selinux-pokemem-v3-2-0bafbaeafe50@google.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Diffstat (limited to 'tools/lib/python')
0 files changed, 0 insertions, 0 deletions
