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]

I investigated a bit whether this caused a race condition; but that is not the case since the seccomp filter has already been applied even if the thread hasn't spawned yet. And even if a child process hits the seccomp filter before the thread is ready, it will at that point simply block until the thread has come online, can you confirm that? (E.g. by resolving this comment)

For the pty case there is no potential for a race because of the "green light" mechanism, so this was the only place where I put some extra attention during review.

I do think moving it in the event loop in the future still might be a good idea, but for now using a thread makes for easier maintainability, and we simply don't have the time to fine tine this further. I'll park it as an issue.

[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)