Protect a bubblewrap (bwrap) sandbox against the TIOCSTI terminal-injection escape (CVE-2017-5226) by detaching it from the controlling terminal with --new-session, and understand the interactivity tradeoff involved.

Documented steps

1. Detach the sandbox from the controlling terminal before running any untrusted, non-interactive command: `bwrap --new-session --unshare-pid --ro-bind /usr /usr --proc /proc --dev /dev COMMAND`. Per bwrap.xml (https://raw.githubusercontent.com/containers/bubblewrap/main/bwrap.xml), '--new-session: Create a new terminal session for the sandbox (calls setsid()). This disconnects the sandbox from the controlling terminal which means the sandbox can't for instance inject input into the terminal.'
2. If `--new-session` cannot be used because the sandboxed program legitimately needs the real controlling TTY, mitigate the same risk with a seccomp filter blocking `ioctl(TIOCSTI)` instead — bwrap.xml states: 'if you don't use --new-session, it is recommended to use seccomp to disallow the TIOCSTI ioctl, otherwise the application can feed keyboard input to the terminal which can e.g. lead to out-of-sandbox command execution (see CVE-2017-5226).'
3. Reproduce the official minimal-shell example, which uses `--new-session` even for an interactive `bash`: `bwrap --ro-bind /usr /usr --symlink usr/lib64 /lib64 --proc /proc --dev /dev --unshare-pid --new-session bash` (README.md 'Usage' section).
4. Confirm the tradeoff by testing job control: after adding `--new-session`, a program expecting terminal-associated signals (e.g. Ctrl-C forwarding tied to the old session) inside the sandbox may behave differently, since the process is now in a new, detached session.
5. Default to `--new-session` unconditionally for batch/CI/non-interactive uses of bwrap, per README.md's Limitations section: 'If you are not filtering out TIOCSTI commands using seccomp filters, argument --new-session is needed to protect against out-of-sandbox command execution.'