Hi Thanks for the patch ! On Thu, Jun 13, 2024 at 6:40 AM Adrian Ratiu <adrian.ratiu@xxxxxxxxxxxxx> 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@xxxxxxxxxxxx>. > 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@xxxxxxxxxxxx> > Cc: Doug Anderson <dianders@xxxxxxxxxxxx> > Cc: Kees Cook <keescook@xxxxxxxxxxxx> > Cc: Jann Horn <jannh@xxxxxxxxxx> > Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > Cc: Randy Dunlap <rdunlap@xxxxxxxxxxxxx> > Cc: Christian Brauner <brauner@xxxxxxxxxx> > Cc: Jeff Xu <jeffxu@xxxxxxxxxx> > Co-developed-by: Mike Frysinger <vapier@xxxxxxxxxxxx> > Signed-off-by: Mike Frysinger <vapier@xxxxxxxxxxxx> > Signed-off-by: Adrian Ratiu <adrian.ratiu@xxxxxxxxxxxxx> Reviewed-by: Jeff Xu <jeffxu@xxxxxxxxxxxx> Tested-by: Jeff Xu <jeffxu@xxxxxxxxxxxx> [1] https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/764773 -Jeff Xu -Jeff