Hi,
On Wed, Feb 21, 2024 at 1:06 PM 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 appeared started causing drama like [1]. The
> /proc/*/mem exploits 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.
>
> As part of hardening against these types of attacks, distrbutions
> can restrict /proc/*/mem to only allow writes when they makes sense,
> like in case of debuggers which have ptrace permissions, as they
> are able to access memory anyway via PTRACE_POKEDATA and friends.
>
> Dropping the mode bits disables write access for non-root users.
> Trying to `chmod` the paths back fails as the kernel rejects it.
>
> For users with CAP_DAC_OVERRIDE (usually just root) we have to
> disable the mem_write callback to avoid bypassing the mode bits.
>
> Writes can be used to bypass permissions on memory maps, even if a
> memory region is mapped r-x (as is a program's executable pages),
> the process can open its own /proc/self/mem file and write to the
> pages directly.
>
> Even if seccomp filters block mmap/mprotect calls with W|X perms,
> they often cannot block open calls as daemons want to read/write
> their own runtime state and seccomp filters cannot check file paths.
> Write calls also can't be blocked in general via seccomp.
>
> 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 on layer fails.
>
> [1] https://lwn.net/Articles/476947/
> [2] https://issues.chromium.org/issues/40089045
>
> Based on an initial patch by Mike Frysinger <vapier@xxxxxxxxxxxx>.
>
> Cc: Guenter Roeck <groeck@xxxxxxxxxxxx>
> Cc: Doug Anderson <dianders@xxxxxxxxxxxx>
> Signed-off-by: Mike Frysinger <vapier@xxxxxxxxxxxx>
> Signed-off-by: Adrian Ratiu <adrian.ratiu@xxxxxxxxxxxxx>
> ---
> Tested on next-20240220.
>
> I would really like to avoid depending on CONFIG_MEMCG which is
> required for the struct mm_stryct "owner" pointer.
>
> Any suggestions how check the ptrace owner without MEMCG?
> ---
> fs/proc/base.c | 26 ++++++++++++++++++++++++--
> security/Kconfig | 13 +++++++++++++
> 2 files changed, 37 insertions(+), 2 deletions(-)
Thanks for posting this! This looks reasonable to me, but I'm nowhere
near an expert on this so I won't add a Reviewed-by tag.
This feels like the kind of thing that Kees might be interested in
reviewing, so adding him to the "To" list.
