Security & code-quality findings from RustDesk maintainer review (rustdesk/rustdesk#15420)

[fxd0h]

Tracking issue for the security and code-quality findings raised in the RustDesk maintainer's security review of libdrmtap-sys 0.4.3, the privileged TCB behind rustdesk/rustdesk#15420.

The review (architecture, full audit, summary) was thorough and is appreciated. It also credited what is already in place: fail-closed/unconditional confinement (the build hard-codes HAVE_LIBCAP/HAVE_SECCOMP and assert!s the link), the PR_SET_NO_NEW_PRIVS -> drop-caps -> default-KILL seccomp sequence, the /dev/dri/ device allowlist, no injection vectors, and correct client-side bounds checks.

TCB findings (this repo)

• Helper: the fd-3 "spawned by libdrmtap" check is not authentication #1 — Helper: the fd-3 check is not authentication
• Helper: drop open/openat from the seccomp allowlist after device init #2 — Helper: drop open/openat from seccomp after device init
• Helper: add exploit-mitigation compile flags (stack-protector, FORTIFY, PIE, RELRO) #3 — Helper: add exploit-mitigation compile flags (stack-protector, FORTIFY, PIE, RELRO)
• Helper: open the DRM node O_RDONLY (capture is read-only) #4 — Helper: open the DRM node O_RDONLY
• Helper: misleading diagnostics (6x wrong perror) + stale drmtap_version() in the privileged TCB #5 — Helper: misleading diagnostics + stale drmtap_version()

Out of scope here (consumer-side, tracked in the RustDesk PR)

The central deployment risk — a world-executable file-capability helper on multi-user hosts — and the related packaging fixes (install root:<group> 0750 instead of 0755, gate the helper copy on the actual feature, keep drm off in default builds, document the multi-user threat model) live in the RustDesk integration, not in libdrmtap, and are being handled on the PR.

On "author-authored privileged C, minimal external scrutiny"

The review fairly noted this code is new and authored by the same person submitting the PR. Tracking these findings publicly, with attribution, is part of addressing that: the security work on the TCB should be transparent and open to review. External scrutiny of the helper is welcome.

---

Reported by the RustDesk maintainer (reviewing as @rustdesk) in the security review of rustdesk/rustdesk#15420.

[fxd0h]

All TCB findings from the maintainer review are now resolved in libdrmtap:

• Helper: the fd-3 "spawned by libdrmtap" check is not authentication #1 fd-3 is not authentication — added the SO_PEERCRED uid check (Harden the privileged helper + fix capture-path correctness (Nvidia, DMA-BUF sync, buffer lifetime) #13)
• Helper: drop open/openat from the seccomp allowlist after device init #2 drop open/openat from seccomp after device init — done (Harden the privileged helper + fix capture-path correctness (Nvidia, DMA-BUF sync, buffer lifetime) #13)
• Helper: add exploit-mitigation compile flags (stack-protector, FORTIFY, PIE, RELRO) #3 exploit-mitigation compile flags — done (Harden the privileged helper + fix capture-path correctness (Nvidia, DMA-BUF sync, buffer lifetime) #13)
• Helper: open the DRM node O_RDONLY (capture is read-only) #4 open the DRM node O_RDONLY — done (Harden the privileged helper + fix capture-path correctness (Nvidia, DMA-BUF sync, buffer lifetime) #13)
• Helper: misleading diagnostics (6x wrong perror) + stale drmtap_version() in the privileged TCB #5 misleading diagnostics + stale drmtap_version() — done (helper: accurate failure diagnostics + coherent library version #17)

The consumer-side deployment items (0750 install, gating the helper copy, keeping drm off by default, multi-user threat model docs) live in the RustDesk integration and continue on rustdesk/rustdesk#15420, not here. Closing this tracking issue.