I could not understand why this pull request was merged:


According to PR:

Enable filtering of system calls using seccomp-bpf: allow only explicitly allowlisted (expected) syscalls to be called.

The syscall sandboxing implemented in this PR is an experimental feature currently available only under Linux x86-64.

Can someone help me understand how does this help as as a user with examples?

1 Answer 1


In general, in order for a thread to interact with any resource external to itself (such as disk I/O, other processes, other threads, etc.), it does so through the use of system calls. There are many system calls, many which could be dangerous in the right context, and many which a thread is not going to use. Syscall sandboxing thus restricts the system calls that a thread is allowed to use. Attempting to use any syscalls outside of the allowlist will result in the OS terminating the process rather than allowing execution to continue.

For Bitcoin Core, this is not going to do much during normal operation. However it can help mitigate the effects of unknown vulnerabilities. For example, suppose there were a buffer overrun vulnerability which allows an attacker to execute arbitrary shellcode. Such shellcode could contain an execve syscall which spawns a ssh daemon allowing the attacker remote access into the machine. If seccomp-bpf is enabled, and the thread where this attack would occur does not allow the execve syscall, then an attack of this sort would fail because the process would be terminated as soon as execve were attempted. This can make it harder for the vulnerability to be exploited as a RCE and limit what an attacker can do.

  • How would this work for Win or Mac?
    – user103136
    Commented Jan 2, 2022 at 3:40
  • This doesn't turn the vulnerability from a RCE to just a crash. If any thread of the program is compromised, it can easily force other threads to do whatever it wants (by overwriting their stack, for example). While no thread has access to execve, many of them have access to the network and the filesystem, which is sufficient. So this only affects vulnerabilities where the amount of executable code is very limited and can't be increased with a multiple-stage exploit. I think the intersection of this set with the set of vulnerabilities that make arbitrary execve possible is not very large. Commented Jan 2, 2022 at 9:54
  • @Prayank AFAIK, neither Windows nor Mac have this this feature.
    – Ava Chow
    Commented Jan 2, 2022 at 18:52
  • @thedefault. Indeed, there are many other tricks an attacker could do to execute arbitrary code that do not require syscalls, but they are more limited in what they can do. I've edited the answer to reflect that.
    – Ava Chow
    Commented Jan 2, 2022 at 18:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.