security/yama/yama_lsm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
From: Nicolas Bouchinet <nicolas.bouchinet@ssi.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".
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.
Signed-off-by: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>
---
security/yama/yama_lsm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c
index 3d064dd4e03f9eaaf5258b37ad05641b35967995..63b589850a88d35dd6a08b23c14ba1a660e6f1b3 100644
--- a/security/yama/yama_lsm.c
+++ b/security/yama/yama_lsm.c
@@ -352,7 +352,7 @@ static int yama_ptrace_access_check(struct task_struct *child,
int rc = 0;
/* require ptrace target be a child of ptracer on attach */
- if (mode & PTRACE_MODE_ATTACH) {
+ if (mode & (PTRACE_MODE_ATTACH | PTRACE_MODE_READ_FSCREDS)) {
switch (ptrace_scope) {
case YAMA_SCOPE_DISABLED:
/* No additional restrictions. */
@@ -380,7 +380,7 @@ static int yama_ptrace_access_check(struct task_struct *child,
}
}
- if (rc && (mode & PTRACE_MODE_NOAUDIT) == 0)
+ if (rc && (mode & PTRACE_MODE_NOAUDIT) == 0 && (mode & PTRACE_MODE_ATTACH))
report_access("attach", child, current);
return rc;
---
base-commit: 5d8b97c946777118930e1cfb075cab59a139ca7c
change-id: 20250718-yama_fix-ea5c2c4b2fbe
Best regards,
--
Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>
Hello,
kernel test robot noticed "ltp.migrate_pages02.fail" on:
commit: 0d6496041d407998103595db3dc42240f124a7f1 ("[PATCH] lsm: yama: Check for PTRACE_MODE_READ_FSCREDS access")
url: https://github.com/intel-lab-lkp/linux/commits/nicolas-bouchinet-oss-cyber-gouv-fr/lsm-yama-Check-for-PTRACE_MODE_READ_FSCREDS-access/20250718-164849
patch link: https://lore.kernel.org/all/20250718-yama_fix-v1-1-a51455359e67@ssi.gouv.fr/
patch subject: [PATCH] lsm: yama: Check for PTRACE_MODE_READ_FSCREDS access
in testcase: ltp
version: ltp-x86_64-0e4be9201-1_20250726
with following parameters:
test: numa/migrate_pages02
config: x86_64-rhel-9.4-ltp
compiler: gcc-12
test machine: 224 threads 2 sockets Intel(R) Xeon(R) Platinum 8480+ (Sapphire Rapids) with 256G memory
(please refer to attached dmesg/kmsg for entire log/backtrace)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202507310843.52fb528f-lkp@intel.com
Running tests.......
<<<test_start>>>
tag=migrate_pages02 stime=1753707486
cmdline="migrate_pages02"
contacts=""
analysis=exit
<<<test_output>>>
tst_tmpdir.c:316: TINFO: Using /tmp/ltp-5PDNJlpHwH/LTP_mig4NxxK0 as tmpdir (tmpfs filesystem)
tst_test.c:2004: TINFO: LTP version: 20250530-108-g0e4be9201
tst_test.c:2007: TINFO: Tested kernel: 6.16.0-rc2-00013-g0d6496041d40 #1 SMP PREEMPT_DYNAMIC Mon Jul 28 20:46:21 CST 2025 x86_64
tst_kconfig.c:88: TINFO: Parsing kernel config '/proc/config.gz'
tst_kconfig.c:676: TINFO: CONFIG_KASAN kernel option detected which might slow the execution
tst_test.c:1825: TINFO: Overall timeout per run is 0h 02m 00s
migrate_pages02.c:313: TINFO: Using nodes: 0 1
migrate_pages02.c:143: TINFO: current_process, cap_sys_nice: 1
migrate_pages02.c:147: TINFO: private anonymous: 0x7f1006150000
migrate_pages02.c:75: TINFO: pid(6801) migrate pid 0 to node -> 1
migrate_pages02.c:96: TINFO: migrate_pages could not migrate all pages, not migrated: 452
migrate_pages02.c:125: TPASS: pid(6801) addr 0x7f1006150000 is on expected node: 1
migrate_pages02.c:75: TINFO: pid(6801) migrate pid 0 to node -> 0
migrate_pages02.c:125: TPASS: pid(6801) addr 0x7f1006150000 is on expected node: 0
migrate_pages02.c:159: TINFO: shared anonymous: 0x7f1006150000
migrate_pages02.c:75: TINFO: pid(6801) migrate pid 0 to node -> 1
migrate_pages02.c:96: TINFO: migrate_pages could not migrate all pages, not migrated: 452
migrate_pages02.c:125: TPASS: pid(6801) addr 0x7f1006150000 is on expected node: 1
migrate_pages02.c:167: TINFO: child shared anonymous, cap_sys_nice: 1
migrate_pages02.c:75: TINFO: pid(6803) migrate pid 0 to node -> 0
migrate_pages02.c:125: TPASS: pid(6803) addr 0x7f100614f000 is on expected node: 0
migrate_pages02.c:125: TPASS: pid(6801) addr 0x7f1006150000 is on expected node: 0
migrate_pages02.c:143: TINFO: current_process, cap_sys_nice: 0
migrate_pages02.c:147: TINFO: private anonymous: 0x7f1006150000
migrate_pages02.c:75: TINFO: pid(6801) migrate pid 0 to node -> 1
migrate_pages02.c:96: TINFO: migrate_pages could not migrate all pages, not migrated: 452
migrate_pages02.c:125: TPASS: pid(6801) addr 0x7f1006150000 is on expected node: 1
migrate_pages02.c:75: TINFO: pid(6801) migrate pid 0 to node -> 0
migrate_pages02.c:125: TPASS: pid(6801) addr 0x7f1006150000 is on expected node: 0
migrate_pages02.c:159: TINFO: shared anonymous: 0x7f1006150000
migrate_pages02.c:75: TINFO: pid(6801) migrate pid 0 to node -> 1
migrate_pages02.c:96: TINFO: migrate_pages could not migrate all pages, not migrated: 452
migrate_pages02.c:125: TPASS: pid(6801) addr 0x7f1006150000 is on expected node: 1
migrate_pages02.c:167: TINFO: child shared anonymous, cap_sys_nice: 0
migrate_pages02.c:75: TINFO: pid(6804) migrate pid 0 to node -> 0
migrate_pages02.c:125: TPASS: pid(6804) addr 0x7f100614f000 is on expected node: 0
migrate_pages02.c:125: TPASS: pid(6801) addr 0x7f1006150000 is on expected node: 1
migrate_pages02.c:200: TINFO: other_process, cap_sys_nice: 1
migrate_pages02.c:75: TINFO: pid(6805) migrate pid 0 to node -> 0
migrate_pages02.c:125: TPASS: pid(6805) addr 0x7f1006150000 is on expected node: 0
migrate_pages02.c:75: TINFO: pid(6806) migrate pid 6805 to node -> 1
migrate_pages02.c:96: TINFO: migrate_pages could not migrate all pages, not migrated: 362
migrate_pages02.c:125: TPASS: pid(6805) addr 0x7f1006150000 is on expected node: 1
migrate_pages02.c:200: TINFO: other_process, cap_sys_nice: 0
migrate_pages02.c:75: TINFO: pid(6807) migrate pid 0 to node -> 0
migrate_pages02.c:125: TPASS: pid(6807) addr 0x7f1006150000 is on expected node: 0
migrate_pages02.c:75: TINFO: pid(6808) migrate pid 6807 to node -> 1
migrate_pages02.c:92: TFAIL: migrate_pages failed ret: -1, : EPERM (1)
migrate_pages02.c:55: TINFO: mem_stats pid: 6807, node: 1
Name: migrate_pages02
Umask: 0000
State: S (sleeping)
Tgid: 6807
Ngid: 0
Pid: 6807
PPid: 6801
TracerPid: 0
Uid: 65534 65534 65534 65534
Gid: 0 0 0 0
FDSize: 64
Groups:
NStgid: 6807
NSpid: 6807
NSpgid: 6801
NSsid: 2420
Kthread: 0
VmPeak: 2868 kB
VmSize: 2868 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 0 kB
VmRSS: 0 kB
RssAnon: 0 kB
RssFile: 0 kB
RssShmem: 0 kB
VmData: 348 kB
VmStk: 136 kB
VmExe: 132 kB
VmLib: 1548 kB
VmPTE: 48 kB
VmSwap: 0 kB
HugetlbPages: 0 kB
CoreDumping: 0
THP_enabled: 1
untag_mask: 0xffffffffffffffff
Threads: 1
SigQ: 0/444866
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000004
SigCgt: 0000000000000000
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 000001ffffffffff
CapAmb: 0000000000000000
NoNewPrivs: 0
Seccomp: 0
Seccomp_filters: 0
Speculation_Store_Bypass: thread vulnerable
SpeculationIndirectBranch: conditional enabled
Cpus_allowed: ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff
Cpus_allowed_list: 0-223
Mems_allowed: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000003
Mems_allowed_list: 0-1
voluntary_ctxt_switches: 5
nonvoluntary_ctxt_switches: 0
cat: /proc/6807/numa_maps: Permission denied
migrate_pages02.c:65: TINFO: Node id: 1, size: 117471789056, free: 106811031552
migrate_pages02.c:129: TFAIL: pid(6807) addr 0x7f1006150000 not on expected node: 0 , expected 1
migrate_pages02.c:55: TINFO: mem_stats pid: 6807, node: 1
Name: migrate_pages02
Umask: 0000
State: S (sleeping)
Tgid: 6807
Ngid: 0
Pid: 6807
PPid: 6801
TracerPid: 0
Uid: 65534 65534 65534 65534
Gid: 0 0 0 0
FDSize: 64
Groups:
NStgid: 6807
NSpid: 6807
NSpgid: 6801
NSsid: 2420
Kthread: 0
VmPeak: 2904 kB
VmSize: 2868 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 0 kB
VmRSS: 0 kB
RssAnon: 0 kB
RssFile: 0 kB
RssShmem: 0 kB
VmData: 348 kB
VmStk: 136 kB
VmExe: 132 kB
VmLib: 1548 kB
VmPTE: 48 kB
VmSwap: 0 kB
HugetlbPages: 0 kB
CoreDumping: 0
THP_enabled: 1
untag_mask: 0xffffffffffffffff
Threads: 1
SigQ: 0/444866
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000010000
SigIgn: 0000000000000006
SigCgt: 0000000000000000
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 000001ffffffffff
CapAmb: 0000000000000000
NoNewPrivs: 0
Seccomp: 0
Seccomp_filters: 0
Speculation_Store_Bypass: thread vulnerable
SpeculationIndirectBranch: conditional enabled
Cpus_allowed: ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff
Cpus_allowed_list: 0-223
Mems_allowed: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000003
Mems_allowed_list: 0-1
voluntary_ctxt_switches: 7
nonvoluntary_ctxt_switches: 0
cat: /proc/6807/numa_maps: Permission denied
migrate_pages02.c:65: TINFO: Node id: 1, size: 117471789056, free: 106811031552
Summary:
passed 13
failed 2
broken 0
skipped 0
warnings 0
incrementing stop
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=1 corefile=no
cutime=0 cstime=11
<<<test_end>>>
INFO: ltp-pan reported some tests FAIL
LTP Version: 20250530-108-g0e4be9201
###############################################################
Done executing testcases.
LTP Version: 20250530-108-g0e4be9201
###############################################################
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20250731/202507310843.52fb528f-lkp@intel.com
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
On Fri, Jul 18, 2025 at 10:47 AM <nicolas.bouchinet@oss.cyber.gouv.fr> wrote: > From: Nicolas Bouchinet <nicolas.bouchinet@ssi.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.
On Fri, Jul 18, 2025 at 04:52:51PM +0200, Jann Horn wrote: > On Fri, Jul 18, 2025 at 10:47 AM <nicolas.bouchinet@oss.cyber.gouv.fr> wrote: > > From: Nicolas Bouchinet <nicolas.bouchinet@ssi.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. I agree with you, it is a bit to harsh, I'll add a new orthogonal sysctl knob that enables this yama behavior. Will send a V2 with it. Thanks, Nicolas
On Fri, Jul 18, 2025 at 04:52:51PM +0200, Jann Horn wrote: > On Fri, Jul 18, 2025 at 10:47 AM <nicolas.bouchinet@oss.cyber.gouv.fr> wrote: > > From: Nicolas Bouchinet <nicolas.bouchinet@ssi.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) > Yes my bad, I should have sent the hidepid [1] patch in the same batch. The idea here is to take "hidepid=ptraceable" into account. Which already calls yama with `PTRACE_MODE_READ_FSCREDS`. > > 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. Yes, this patch doesn't work alone it needs to be coupled with [1]: https://lore.kernel.org/all/20250718-hidepid_fix-v1-1-3fd5566980bc@ssi.gouv.fr/.
On Fri, Jul 18, 2025 at 5:55 PM Nicolas Bouchinet <nicolas.bouchinet@oss.cyber.gouv.fr> wrote: > On Fri, Jul 18, 2025 at 04:52:51PM +0200, Jann Horn wrote: > > On Fri, Jul 18, 2025 at 10:47 AM <nicolas.bouchinet@oss.cyber.gouv.fr> wrote: > > > From: Nicolas Bouchinet <nicolas.bouchinet@ssi.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) > > > > Yes my bad, I should have sent the hidepid [1] patch in the same batch. > The idea here is to take "hidepid=ptraceable" into account. Which > already calls yama with `PTRACE_MODE_READ_FSCREDS`. To be clearer: "if (mode & (PTRACE_MODE_ATTACH | PTRACE_MODE_READ_FSCREDS))" does not make sense, because it expands to "if (mode & (PTRACE_MODE_ATTACH | PTRACE_MODE_READ | PTRACE_MODE_FSCREDS))", which is always true.
Note that a hidepid patch has also been sent [1].
[1]: https://lore.kernel.org/all/20250718-hidepid_fix-v1-1-3fd5566980bc@ssi.gouv.fr/
Best regards,
Nicolas
On 7/18/25 10:47, nicolas.bouchinet@oss.cyber.gouv.fr wrote:
> From: Nicolas Bouchinet <nicolas.bouchinet@ssi.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".
>
> 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.
>
> Signed-off-by: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>
> ---
> security/yama/yama_lsm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c
> index 3d064dd4e03f9eaaf5258b37ad05641b35967995..63b589850a88d35dd6a08b23c14ba1a660e6f1b3 100644
> --- a/security/yama/yama_lsm.c
> +++ b/security/yama/yama_lsm.c
> @@ -352,7 +352,7 @@ static int yama_ptrace_access_check(struct task_struct *child,
> int rc = 0;
>
> /* require ptrace target be a child of ptracer on attach */
> - if (mode & PTRACE_MODE_ATTACH) {
> + if (mode & (PTRACE_MODE_ATTACH | PTRACE_MODE_READ_FSCREDS)) {
> switch (ptrace_scope) {
> case YAMA_SCOPE_DISABLED:
> /* No additional restrictions. */
> @@ -380,7 +380,7 @@ static int yama_ptrace_access_check(struct task_struct *child,
> }
> }
>
> - if (rc && (mode & PTRACE_MODE_NOAUDIT) == 0)
> + if (rc && (mode & PTRACE_MODE_NOAUDIT) == 0 && (mode & PTRACE_MODE_ATTACH))
> report_access("attach", child, current);
>
> return rc;
>
> ---
> base-commit: 5d8b97c946777118930e1cfb075cab59a139ca7c
> change-id: 20250718-yama_fix-ea5c2c4b2fbe
>
> Best regards,
© 2016 - 2026 Red Hat, Inc.