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! |
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/
|
Opened #1078 to track implementing NOEXEC on FreeBSD. |
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/ ↩