Implement support for NOEXEC #1073
Conversation
|
Looks like our MSRV doesn't support |
|
We can certainly consider that. How ugly is the workaround if we don't raise the MSRV to 1.77? |
|
I believe it would be create a zeroed instance of |
|
Looks like Ubuntu LTS is still stuck at rustc 1.75. |
bjorn3
force-pushed
the
noexec2
branch
3 times, most recently
from
c01b452 to
864b19e
Compare
|
Two general questions:
|
FreeBSD doesn't have seccomp support at all AFAIK (or at least I couldn't find any man page for it), so we would indeed need a dynamic library there.
Should be 5.0, but I don't have a VM ready to check. |
I recall that that was fine, nice! |
|
Opened #1078 to track implementing NOEXEC on FreeBSD. |
|
Documentation is still missing, tracked in #1095 |
There was a problem hiding this comment.
Functionality LGTM, but I have left improvement suggestions on bjorn3#4 to make sure this code remains more understandable if we have to look at it again in the future.
Particular points to look at:
- Some separation of the fd handling / seccomp programming; there's a lot going on here.
- DRY'ing in
handle_notifications: the business logic of this function is pretty simple and it would be nice if that is clearly visible
To enable adding exceptions to the file closer in run_command
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 [^1]. 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. [^1]: https://lwn.net/Articles/1002371/
this will prevent problems if this code is edited in the future
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 1. 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
Footnotes
https://lwn.net/Articles/1002371/ ↩