linux-kernel - Re: [PATCH] lsm: yama: Check for PTRACE_MODE_READ

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAG48ez23HLtb9GJ-BbSXaWFhdPjXyFNED9fbuyaNP5EXJ_Wv8w@mail.gmail.com>
Date: Fri, 18 Jul 2025 16:52:51 +0200
From: Jann Horn <jannh@...gle.com>
To: nicolas.bouchinet@....cyber.gouv.fr
Cc: Kees Cook <kees@...nel.org>, Paul Moore <paul@...l-moore.com>, 
	James Morris <jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>, 
	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Olivier Bal-Petre <olivier.bal-petre@....cyber.gouv.fr>, 
	Nicolas Bouchinet <nicolas.bouchinet@....gouv.fr>
Subject: Re: [PATCH] lsm: yama: Check for PTRACE_MODE_READ_FSCREDS access

On Fri, Jul 18, 2025 at 10:47 AM <nicolas.bouchinet@....cyber.gouv.fr> wrote:
> From: Nicolas Bouchinet <nicolas.bouchinet@....gouv.fr>
>
> Currently, yama only checks if the `PTRACE_MODE_ATTACH` mode is set
> during the `yama_ptrace_access_check()` LSM hook implementation.
>
> In cases of call with the `PTRACE_MODE_READ_FSCREDS` mode, nothing
> happens. Thus, yama does not interact properly with the
> "hidepid=ptraceable" option.
>
> hidepid's "ptraceable" option being documented as follow :
>
> - hidepid=ptraceable or hidepid=4 means that procfs should only contain
>   `/proc/<pid>/` directories that the caller can ptrace.
>
> This patch simply add yama a `PTRACE_MODE_READ_FSCREDS` mode check to
> enable an interaction with "hidepid=ptraceable".

Please note that PTRACE_MODE_READ_FSCREDS is actually a combination of
two flags, and the intention is that the PTRACE_MODE_REALCREDS /
PTRACE_MODE_FSCREDS part of the flags should basically only be used to
determine where to read the caller's credentials from:

/* shorthands for READ/ATTACH and FSCREDS/REALCREDS combinations */
#define PTRACE_MODE_READ_FSCREDS (PTRACE_MODE_READ | PTRACE_MODE_FSCREDS)
#define PTRACE_MODE_READ_REALCREDS (PTRACE_MODE_READ | PTRACE_MODE_REALCREDS)
#define PTRACE_MODE_ATTACH_FSCREDS (PTRACE_MODE_ATTACH | PTRACE_MODE_FSCREDS)
#define PTRACE_MODE_ATTACH_REALCREDS (PTRACE_MODE_ATTACH |
PTRACE_MODE_REALCREDS)

> Combined with hidepid=ptraceable, the following behaviors will then
> happen while reading in `/proc/<pid>`:
>
> - "restricted": A process that has a predefined relationship with the
>   inferior will see the inferior process in `/proc`.
>
> - "admin-only": A process that has the CAP_SYS_PTRACE will be able to
>   see every processes in `/proc`.
>
> - "no attach": A process will not see anything but itself in
>   `/proc/<pid>/`.
>
> It is important to note that the combination of "hidepid=ptraceable" and
> yama "no attach" also makes PIDs invisible to root.
>
> No access reports are logged in case of denied access with
> `PTRACE_MODE_READ_FSCREDS` to avoid flooding kernel logs.

This seems like a major semantic change; I believe it essentially
means that commands like "ps" stop working entirely on systems that
enable hidepid. While that might be desirable in some scenarios, I
think changing the semantics like this without making it opt-in
through a new sysctl knob or such would be a bad idea.