Message-ID: <3304e0-66734e80-1857-33d83680@76729138>
Date: Wed, 19 Jun 2024 22:31:49 +0100
From: "Adrian Ratiu" <adrian.ratiu@...labora.com>
To: "Kees Cook" <kees@...nel.org>
Cc: "Jeff Xu" <jeffxu@...omium.org>, linux-fsdevel@...r.kernel.org, linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org, linux-doc@...r.kernel.org, kernel@...labora.com, gbiv@...gle.com, ryanbeltran@...gle.com, inglorion@...gle.com, ajordanr@...gle.com, jorgelo@...omium.org, "Guenter Roeck" <groeck@...omium.org>, "Doug Anderson" <dianders@...omium.org>, "Jann Horn" <jannh@...gle.com>, "Andrew Morton" <akpm@...ux-foundation.org>, "Randy Dunlap" <rdunlap@...radead.org>, "Christian Brauner" <brauner@...nel.org>, "Jeff Xu" <jeffxu@...gle.com>, "Mike Frysinger" <vapier@...omium.org>
Subject: Re: [PATCH v6 2/2] proc: restrict /proc/pid/mem

On Wednesday, June 19, 2024 23:41 EEST, Kees Cook <kees@...nel.org> wrote:

> On Tue, Jun 18, 2024 at 03:39:44PM -0700, Jeff Xu wrote:
> > Hi
> > 
> > Thanks for the patch !
> > 
> > On Thu, Jun 13, 2024 at 6:40 AM Adrian Ratiu <adrian.ratiu@...labora.com> wrote:
> > >
> > > Prior to v2.6.39 write access to /proc/<pid>/mem was restricted,
> > > after which it got allowed in commit 198214a7ee50 ("proc: enable
> > > writing to /proc/pid/mem"). Famous last words from that patch:
> > > "no longer a security hazard". :)
> > >
> > > Afterwards exploits started causing drama like [1]. The exploits
> > > using /proc/*/mem can be rather sophisticated like [2] which
> > > installed an arbitrary payload from noexec storage into a running
> > > process then exec'd it, which itself could include an ELF loader
> > > to run arbitrary code off noexec storage.
> > >
> > > One of the well-known problems with /proc/*/mem writes is they
> > > ignore page permissions via FOLL_FORCE, as opposed to writes via
> > > process_vm_writev which respect page permissions. These writes can
> > > also be used to bypass mode bits.
> > >
> > > To harden against these types of attacks, distrbutions might want
> > > to restrict /proc/pid/mem accesses, either entirely or partially,
> > > for eg. to restrict FOLL_FORCE usage.
> > >
> > > Known valid use-cases which still need these accesses are:
> > >
> > > * Debuggers which also have ptrace permissions, so they can access
> > > memory anyway via PTRACE_POKEDATA & co. Some debuggers like GDB
> > > are designed to write /proc/pid/mem for basic functionality.
> > >
> > > * Container supervisors using the seccomp notifier to intercept
> > > syscalls and rewrite memory of calling processes by passing
> > > around /proc/pid/mem file descriptors.
> > >
> > > There might be more, that's why these params default to disabled.
> > >
> > > Regarding other mechanisms which can block these accesses:
> > >
> > > * seccomp filters can be used to block mmap/mprotect calls with W|X
> > > perms, but they often can't block open calls as daemons want to
> > > read/write their runtime state and seccomp filters cannot check
> > > file paths, so plain write calls can't be easily blocked.
> > >
> > > * Since the mem file is part of the dynamic /proc/<pid>/ space, we
> > > can't run chmod once at boot to restrict it (and trying to react
> > > to every process and run chmod doesn't scale, and the kernel no
> > > longer allows chmod on any of these paths).
> > >
> > > * SELinux could be used with a rule to cover all /proc/*/mem files,
> > > but even then having multiple ways to deny an attack is useful in
> > > case one layer fails.
> > >
> > > Thus we introduce four kernel parameters to restrict /proc/*/mem
> > > access: open-read, open-write, write and foll_force. All these can
> > > be independently set to the following values:
> > >
> > > all     => restrict all access unconditionally.
> > > ptracer => restrict all access except for ptracer processes.
> > >
> > > If left unset, the existing behaviour is preserved, i.e. access
> > > is governed by basic file permissions.
> > >
> > > Examples which can be passed by bootloaders:
> > >
> > > proc_mem.restrict_foll_force=all
> > > proc_mem.restrict_open_write=ptracer
> > > proc_mem.restrict_open_read=ptracer
> > > proc_mem.restrict_write=all
> > >
> > > These knobs can also be enabled via Kconfig like for eg:
> > >
> > > CONFIG_PROC_MEM_RESTRICT_WRITE_PTRACE_DEFAULT=y
> > > CONFIG_PROC_MEM_RESTRICT_FOLL_FORCE_PTRACE_DEFAULT=y
> > >
> > > Each distribution needs to decide what restrictions to apply,
> > > depending on its use-cases. Embedded systems might want to do
> > > more, while general-purpouse distros might want a more relaxed
> > > policy, because for e.g. foll_force=all and write=all both break
> > > break GDB, so it might be a bit excessive.
> > >
> > > Based on an initial patch by Mike Frysinger <vapier@...omium.org>.
> > >
> > It is noteworthy that ChromeOS has benefited from blocking
> > /proc/pid/mem write since 2017 [1], owing to the patch implemented by
> > Mike Frysinger.
> > 
> > It is great that upstream can consider this patch, ChromeOS will use
> > the solution once it is accepted.
> > 
> > > Link: https://lwn.net/Articles/476947/ [1]
> > > Link: https://issues.chromium.org/issues/40089045 [2]
> > > Cc: Guenter Roeck <groeck@...omium.org>
> > > Cc: Doug Anderson <dianders@...omium.org>
> > > Cc: Kees Cook <keescook@...omium.org>
> > > Cc: Jann Horn <jannh@...gle.com>
> > > Cc: Andrew Morton <akpm@...ux-foundation.org>
> > > Cc: Randy Dunlap <rdunlap@...radead.org>
> > > Cc: Christian Brauner <brauner@...nel.org>
> > > Cc: Jeff Xu <jeffxu@...gle.com>
> > > Co-developed-by: Mike Frysinger <vapier@...omium.org>
> > > Signed-off-by: Mike Frysinger <vapier@...omium.org>
> > > Signed-off-by: Adrian Ratiu <adrian.ratiu@...labora.com>
> > 
> > Reviewed-by: Jeff Xu <jeffxu@...omium.org>
> > Tested-by: Jeff Xu <jeffxu@...omium.org>
> > [1] https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/764773
> 
> Thanks for the testing! What settings did you use? I think Chrome OS was
> effectively doing this?
> 
> PROC_MEM_RESTRICT_OPEN_READ_OFF=y
> CONFIG_PROC_MEM_RESTRICT_OPEN_WRITE_ALL=y
> CONFIG_PROC_MEM_RESTRICT_WRITE_ALL=y
> CONFIG_PROC_MEM_RESTRICT_FOLL_FORCE_ALL=y

Correct except for CONFIG_PROC_MEM_RESTRICT_OPEN_WRITE_ALL=y
which will make ChromeOS boot loop because upstart/systemd-tmpfiles
will fail and trigger a recovery + reboot, then the kernel will again block
opening the file and so on. :)

ChromeOS effectively only blocks all writes which also blocks all foll_force.

> 
> Though I don't see the FOLL_FORCE changes in the linked Chrome OS patch,
> but I suspect it's unreachable with
> CONFIG_PROC_MEM_RESTRICT_OPEN_WRITE_ALL=y.
 
That is correct, CONFIG_PROC_MEM_RESTRICT_OPEN_WRITE_ALL=y also
blocks FOLL_FORCE.

The idea there is to restrict writes entirely in production images via
Kconfig and then relax the restriction in dev/test images via boot params
proc_mem.restrict_write=ptracer proc_mem.restrict_foll_force=ptracer

See this CL:
https://chromium-review.googlesource.com/c/chromiumos/platform/vboot_reference/+/5631026

Powered by blists - more mailing lists