From: Christian Brauner <brauner@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Christian Brauner <brauner@kernel.org>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [GIT PULL for v6.11] vfs procfs
Date: Fri, 12 Jul 2024 15:58:52 +0200 [thread overview]
Message-ID: <20240712-vfs-procfs-ce7e6c7cf26b@brauner> (raw)
Hey Linus,
/* Summary */
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.
/* Testing */
clang: Debian clang version 16.0.6 (26)
gcc: (Debian 13.2.0-24)
All patches are based on v6.10-rc1 and have been sitting in linux-next.
No build failures or warnings were observed.
/* Conflicts */
No known conflicts.
The following changes since commit 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0:
Linux 6.10-rc1 (2024-05-26 15:20:12 -0700)
are available in the Git repository at:
git@gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs tags/vfs-6.11.procfs
for you to fetch changes up to 39efa92f9e5fceb44edef5536c58e3750b9d638d:
proc: restrict /proc/pid/mem (2024-06-18 12:26:54 +0200)
Please consider pulling these changes from the signed vfs-6.11.procfs tag.
Thanks!
Christian
----------------------------------------------------------------
vfs-6.11.procfs
----------------------------------------------------------------
Adrian Ratiu (2):
proc: pass file instead of inode to proc_mem_open
proc: restrict /proc/pid/mem
Documentation/admin-guide/kernel-parameters.txt | 38 +++++
fs/proc/base.c | 203 +++++++++++++++++++++++-
fs/proc/internal.h | 2 +-
fs/proc/task_mmu.c | 6 +-
fs/proc/task_nommu.c | 2 +-
security/Kconfig | 121 ++++++++++++++
6 files changed, 363 insertions(+), 9 deletions(-)
next reply other threads:[~2024-07-12 13:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-12 13:58 Christian Brauner [this message]
2024-07-15 11:17 ` [GIT PULL for v6.11] vfs procfs Christian Brauner
2024-07-15 19:20 ` Linus Torvalds
2024-07-22 14:49 ` Christian Brauner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240712-vfs-procfs-ce7e6c7cf26b@brauner \
--to=brauner@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox