DF-0074 / env.txt
============================================================
DF-0074 PoC environment โ guest run on master DEV
============================================================
uname: DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026
(X86_64_GENERIC, INVARIANTS ON)
root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64
cc: cc 8.3 [DragonFly] Release/2019-02-22
sysctls (verified):
vfs.usermount = 0 (default)
kern.securelevel = -1 (insecure โ full operation)
vm.randomize_mmap = 0 (KASLR OFF)
CPU hardening (from audit-wide environment table โ verified on this DEV build):
SMAP = OFF
SMEP = OFF
KASLR = OFF
PTI/KPTI = OFF
NX = ON (irrelevant given no SMEP)
INVARIANTS/KASSERT = ON (X86_64_GENERIC default; KKASSERT traps fire)
Reachability for the DIOCGSLICEINFO trigger:
- Default devfs: /dev/vn0s1, /dev/md0s*, /dev/vbd0s* are root:operator crw-r-----
and operator contains only root, so maxx gets EACCES on open() at the devfs layer.
- EVEN WITH chown vn0s1 -> maxx + chmod 666 + sysctl vfs.usermount=1,
maxx STILL gets EPERM on open(/dev/vn0s1). The hard barrier is
diskopen():sys/kern/subr_disk.c:1072 -> caps_priv_check_self(SYSCAP_RESTRICTEDROOT),
which (sys/kern/kern_caps.c:328-331) requires cr_uid == 0 (SYSCAP_RESTRICTEDROOT
has neither __SYSCAP_NOROOTTEST nor __SYSCAP_WHEELOK, so wheel-group membership
does NOT help). The check fires on the disk layer, BEFORE the underlying
device's d_open (vnopen/mdopen). Same RESTRICTEDROOT gate is on vnconfig
(sys/dev/disk/vn/vn.c:434). See VERDICT.md "Reachability".
- Therefore the bug is UID-0-ONLY to trigger on a default DragonFly kernel.
This is a hard blocker for unprivileged -> root escalation.
Patched #1 kernel (this run's fix-validation kernel):
DragonFly 6.5-DEVELOPMENT #1: Sat Jul 4 16:48:34 UTC 2026
sha256(/boot/kernel/kernel) = 58d7f052637e8b048f6b8edd7c9be7e66f5d6b26a7067a6d435856bc237716cd