re: bin/58630: dtrace is "hit or miss", but mostly "miss"

[gnats-admin%netbsd.org@localhost]

The following reply was made to PR bin/58630; it has been noted by GNATS.

From: matthew green <mrg%eterna23.net@localhost>
To: gnats-bugs%netbsd.org@localhost, rvp%SDF.ORG@localhost
Cc: gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, he%NetBSD.org@localhost
Subject: re: bin/58630: dtrace is "hit or miss", but mostly "miss"
Date: Sat, 24 Aug 2024 16:24:16 +1000

 >  Is /dev/ksyms world-readable on the other systems, or is dtrace setuid =
 there?
 
 some time between netbsd-7 and netbsd-9 the default for /dev/ksyms
 changed from 444 to 440.  ah, here it is:
 
 date: 2018-07-21 00:46:56 -0700;  author: maxv;  state: Exp;  lines: +2 -2=
 ;  commitid: 4dw22L6uN8Y2AYKA;
 Create /dev/ksyms as "440 $g_kmem". This prevents unprivileged users from
 reading the kernel symbols. Discussed in January 2018 on tech-kern@,
 reported by maya@, tested by tih@.
 
 >  I wonder if something like this would do instead of reading from /dev/k=
 syms?
 [ .. ]
 >  +		if (sysctlbyname("machdep.booted_kernel", tmp, &len, NULL, 0) =3D=3D=
  0) =
 
 
 no, this doesn't work if the boot media isn't mounted
 and it doesn't support modules, or KALSR, or in the case
 i've installed a new /netbsd but haven't yet rebooted.
 
 this is a caveat of dtrace that i don't see - i normally
 run it as root.  one could enable access to /dev/ksyms
 by accepting the info leak (kernel addresses) to all or
 perhaps making relevant users part of kmem group.
 
 we could make dtrace more obvious about this failure mode.
 
 
 .mrg.