SystemCallFilter doesn't support excluding execve

[ovhpse]

systemd version the issue has been seen with

systemd-253.2-1.fc38

Used distribution

Fedora 38

Linux kernel version used

6.2.14-300.fc38.x86_64

CPU architectures issue was seen on

x86_64

Component

systemd

Expected behaviour you didn't see

We are able to use SystemCallFilter=~ execve.
It may not be possible to completely restrict execve as systemd need to launch the command specified in ExecStart.

systemd/src/shared/exec-util.c

Line 488 in 8521338

int fexecve_or_execve(int executable_fd, const char *executable, char *const argv[], char *const envp[]) {

At least the service should not be able to execve any other command than the one speficied in the ExecStart directive.
This, coupled with MemoryDenyWriteExecute=yes, is a powerful way to prevent an attacker from running any new code for every service that don't need to launch new process (of which they are many).

https://www.freedesktop.org/software/systemd/man/systemd.exec.html#MemoryDenyWriteExecute=

Unexpected behaviour you saw

Job for test.service failed because a fatal signal was delivered causing the control process to dump core. See "systemctl status test.service" and "journalctl -xeu test.service" for details.

Steps to reproduce the problem

Add to /etc/systemd/system/test.service:

[Unit]
Description=test

[Service]
Type=oneshot
ExecStart=/usr/bin/echo Success
SystemCallFilter=~ execve

systemctl daemon-reload
systemctl start test

Additional program output to the terminal or log subsystem illustrating the issue

No response

[topimiettinen]

Seccomp filters take effect immediately. The filters are installed by systemd just before the using execve() to switch to the specified executable, so blocking execve() means that the executable can't be executed at all. fexecve() is just a glibc wrapper around execveat(,,, AT_EMPTY_PATH), it's not a separate system call. It could be possible to allow only execveat(,,, AT_EMPTY_PATH) and deny other forms, but then the malicious process would also be able to use fexecve() / execveat(,,, AT_EMPTY_PATH).

Effectively denying all forms of exec*() would be possible, if the kernel had a method for installing a set of seccomp filters, which would be installed later at the time of exec*() call. This is how SELinux setexeccon() works.

Other options could be:

• forcing the process use a LD_PRELOADed library, which would install the filter (like Firejail)
• forcing the process use a special dynamic loader (replacing glibc ld.so), which does the magic (perhaps ld-so-daemon one day)
• use prctl(PR_SET_SYSCALL_USER_DISPATCH) to selectively deny exec*() (not great since the handler resides in the same address space)
• install a nanokernel with KVM, which would only filter system calls but with greater flexibility than seccomp

Even if filtering would be possible, a malicious process could use a combination of munmap() and mmap() calls to simulate exec*() and transfer control to a loaded program. MemoryDenyWriteExecute=yes can prevent some forms of mapping arbitrary executable content, but not all (memfds, writable and executable file systems etc). With kernel 6.3 there's prctl(PR_SET_MDWE), which could be extended to further checks.

Ideally there should be a way to ensure for a process and its children that only those code pages are ever made executable, which are signed and the signature chain is verifiable to the root of trust.

[poettering]

Note that the fact that execve() cannot be filtered is expressly documented in systemd.exec(5):

Note that the execve(), exit(), exit_group(), getrlimit(), rt_sigreturn(), sigreturn() system calls and the system calls for querying time and sleeping are implicitly allow-listed and do not need to be listed explicitly.

[poettering]

Anyway, this here is not implementable with seccomp, the filter apply immediately. Let's clos hence.