DF-2874 — DIOCRECLUSTER: no privilege check; kernel opens the raw disk

FREAD|FWRITE with proc0.p_ucred on the dmsg peer's request (Info —

mitigated by diskopen's SYSCAP_RESTRICTEDROOT gate)

What this pack contains

• dfpeer.c — dmsg wire peer; openwr mode issues BLK_OPEN(RD|WR) and prints the kernel's reply (error=0 = dev_dopen(rawdev, FREAD|FWRITE, S_IFCHR, proc0.p_ucred, ...) succeeded).
• run_f1.sh — full chain attempt as an unprivileged operator-group user.
• run_f1b.sh — the chain at the dmsg-peer position (root harness): BLK_OPEN(RD|WR) → raw write through the channel → root dd readback shows the payload on the raw disk.

Outcome

• Peer position (verified): BLK_OPEN modes=3 -> reply error=0; a 4KB 0x5a write at gap offset 0x77F000000 lands on the raw disk (confirmed by root dd md5) and reads back through the channel.
• Unprivileged position (blocked): a member of group operator cannot even open /dev/vbd0 read-only — diskopen() (sys/kern/subr_disk.c:78-80) enforces caps_priv_check_self(SYSCAP_RESTRICTEDROOT) on every disk volume open, so the ioctl path is effectively root-only on this system. The missing priv_check in diskioctl()/disk_iocom_ioctl() is therefore a defense-in-depth gap (the 0640 root:operator node perms and the absence of any FWRITE-on-node requirement would otherwise let an operator-group user turn read-only device access into kernel-mediated root-credential raw disk R/W).
• Also demonstrated: disk_blk_write/disk_blk_read perform raw I/O with no BLK_OPEN/keyid validation at all — every message the iocom receives is executed with root credentials.

fix.diff

Require FWRITE on the device node for DIOCRECLUSTER (devfs then enforces write permission at open time), making the gate explicit instead of incidental.

DF-2874 VERDICT

Status: not_reproduced for the unprivileged-escalation claim

(blocked by an external gate); the root-credential proxy behavior

itself is verified at the peer position.

Guest: DragonFly 6.5-DEVELOPMENT X86_64_GENERIC (env.txt).

What was verified

1. Peer position (root harness == stand-in for a routed cluster node): BLK_OPEN modes=3 → reply error=0, i.e. dev_dopen(dp->d_rawdev, FREAD|FWRITE, S_IFCHR, proc0.p_ucred, NULL, NULL) (sys/kern/subr_diskiocom.c:281-282) succeeded — the kernel opened the raw boot disk READ-WRITE with root credentials on the message peer's request, even though the device node perms are 0640 root:operator (no write for group) and the fs is mounted. A 4KB write through the channel landed on the raw disk (root dd md5-verified) and read back through the channel.
2. No open validation for I/O: disk_blk_write/disk_blk_read/ _flush/_freeblks never check that a BLK_OPEN happened or validate keyid — every message the iocom receives executes raw I/O with root credentials.
3. Unprivileged chain (blocked): user poc (member of group operator) cannot open /dev/vbd0 even read-only: diskopen() enforces caps_priv_check_self(SYSCAP_RESTRICTEDROOT) (sys/kern/subr_disk.c:78-80) on every disk-volume open, returning EPERM before the DIOCRECLUSTER branch in diskioctl is reachable. Therefore the missing priv_check/FWRITE requirement in diskioctl (subr_disk.c:1191) / disk_iocom_ioctl (subr_diskiocom.c:108-130) is currently mitigated by that gate. Had the gate not been there, 0640 root:operator + O_RDONLY would have been sufficient for operator→root-equivalent raw disk R/W.

Why filed as Info

The kernel-side authorization gap is real (no priv_check, arbitrary fd types accepted via holdfp, proc0.p_ucred raw opens, no peer revalidation), but on this system it is unreachable for unprivileged users. Defense-in-depth recommendation: require FWRITE on the node (devfs then enforces write permission) — fix.diff does exactly that.

Fix validation

fix.diff (FWRITE required for DIOCRECLUSTER) applied, kernel rebuilt: openwr via an O_RDONLY fd returns EPERM; via O_RDWR (root) still works (run.fix.log).