Implement support for NOEXEC (take 2)

[bjorn3]

This is using seccomp syscall filtering of the execve and execveat syscalls. Unlike the original sudo this does not depend on using LD_PRELOAD. Instead SECCOMP_RET_USER_NOTIF is used combined with a thread which allows the first exec (as done by sudo itself) and denies all further execs. This makes it robust against both statically linked executables and executables compiled for a different libc than sudo-rs itself. Sudo-rs just like original sudo does not protect against malicious programs with NOEXEC. It doesn't prevent mapping memory as executable, nor does it protect against future syscalls that do an exec like the planned io_uring exec opcode ¹. And it also doesn't protect against honest programs that intentionally or not allow the user to write to /proc/self/mem for the same reasons as that it doesn't protect against malicious programs.

Fixes #1071
Fixes #1072

---

This is a revival of #1073. It now spawns the handler thread after doing a fork.

Footnotes

1. https://lwn.net/Articles/1002371/ ↩

[squell]

Note: I've merged the changes from close_range into this branch locally, so once you have brought it up to date by rebasing or merging I can quickly re-review if we agree on how the merge conflicts should have been resolved (but I'd prefer you do it so we also have two pairs of eyes on that)

[squell]

As an informational note: io_uring has more drawbacks: https://www.schneier.com/blog/archives/2025/04/new-linux-rootkit.html

There are two possibilities: either Linux will add some seccomp filtering for io_uring at some point or NOEXEC will have to imply “NOIOURING”.