linux-kernel - [GIT PULL for v6.11] vfs procfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240712-vfs-procfs-ce7e6c7cf26b@brauner>
Date: Fri, 12 Jul 2024 15:58:52 +0200
From: Christian Brauner <brauner@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Christian Brauner <brauner@...nel.org>,
	linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: [GIT PULL for v6.11] vfs procfs

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@...olite.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(-)