Linux 6.11 To Allow Tightening Of /proc/[pid]/mem Access For Better Security
([Linux Security] 3 Hours Ago
Restricting mem)
- Reference: 0001478260
- News link: https://www.phoronix.com/news/Linux-6.11-Tightens-Mem-Access
- Source link:
Linux engineer Christian Brauner at Microsoft sent out his various pull requests for areas of the kernel he oversees ahead of the Linux 6.11 merge window. One of the more interesting pull requests from Brauner this cycle are the "vfs procfs" updates that now allow restricting access to the /proc/[pid]/mem files of processes.
The new SECURITY_PROC_MEM_RESTRICT_WRITES Kconfig option allows restricting writes to the mem file of processes unless the current process ptraces to that given task.
Brauner explains in [1]the pull request with the patches from Collabora's Adrian Ratiu:
"This contains work to allow restricting access to /proc/<pid>/mem. Over the years various exploits started abusing /proc/<pid>/mem (cf. [1] and [2]). Specifically [2] is interesting as it installed an arbitrary payload from noexec storage into a running process and then executed it. That payload itself included an ELF loader to run arbitrary code off of noexec storage.
The biggest problem is that /proc/<pid>/mem ignores page permissions by using FOLL_FORCE which was discussed several times on- and off-list.
Unfortunately there are various use-cases using /proc/<pid>/mem making it impossible to just turn it off. They at least include PTRACE_POKEDATA and the seccomp notifier which is used to emulate system calls.
So give userspace a way to restrict access to /proc/<pid>/mem via kernel command line options. Setting them to "all" restricts access for all processes while "ptracer" will allow access to ptracers:
(1) Restrict the use of FOLL_FORCE via proc_mem.restrict_foll_force
(2) Restrict opening /proc/<pid>/mem for reading.
(3) Restrict opening /proc/<pid>/mem for writing.
(4) Restrict writing to /proc/<pid>/mem.
---
The level of fine-grained management isn't my favorite as it requires distributions to have some level of knowledge around the implications of FOLL_FORCE and /proc/<pid>/mem access in general. But the use-cases where /proc/<pid>/mem access is needed do already imply a sophisticated knowledge around its implications. Especially when it comes to the seccomp notifier and gdb to inspect or emulate process state. So that ultimately swayed me to accept this. If we need something simpler I'm all ears."
This new security feature is now awaiting pulling by Linus Torvalds once the v6.11 merge window kicks off, which will begin tomorrow assuming no v6.10 release delays.
[1] https://lore.kernel.org/lkml/20240712-vfs-procfs-ce7e6c7cf26b@brauner/
The new SECURITY_PROC_MEM_RESTRICT_WRITES Kconfig option allows restricting writes to the mem file of processes unless the current process ptraces to that given task.
Brauner explains in [1]the pull request with the patches from Collabora's Adrian Ratiu:
"This contains work to allow restricting access to /proc/<pid>/mem. Over the years various exploits started abusing /proc/<pid>/mem (cf. [1] and [2]). Specifically [2] is interesting as it installed an arbitrary payload from noexec storage into a running process and then executed it. That payload itself included an ELF loader to run arbitrary code off of noexec storage.
The biggest problem is that /proc/<pid>/mem ignores page permissions by using FOLL_FORCE which was discussed several times on- and off-list.
Unfortunately there are various use-cases using /proc/<pid>/mem making it impossible to just turn it off. They at least include PTRACE_POKEDATA and the seccomp notifier which is used to emulate system calls.
So give userspace a way to restrict access to /proc/<pid>/mem via kernel command line options. Setting them to "all" restricts access for all processes while "ptracer" will allow access to ptracers:
(1) Restrict the use of FOLL_FORCE via proc_mem.restrict_foll_force
(2) Restrict opening /proc/<pid>/mem for reading.
(3) Restrict opening /proc/<pid>/mem for writing.
(4) Restrict writing to /proc/<pid>/mem.
---
The level of fine-grained management isn't my favorite as it requires distributions to have some level of knowledge around the implications of FOLL_FORCE and /proc/<pid>/mem access in general. But the use-cases where /proc/<pid>/mem access is needed do already imply a sophisticated knowledge around its implications. Especially when it comes to the seccomp notifier and gdb to inspect or emulate process state. So that ultimately swayed me to accept this. If we need something simpler I'm all ears."
This new security feature is now awaiting pulling by Linus Torvalds once the v6.11 merge window kicks off, which will begin tomorrow assuming no v6.10 release delays.
[1] https://lore.kernel.org/lkml/20240712-vfs-procfs-ce7e6c7cf26b@brauner/
drastic