Seccomp constraints and syscall-level exploit goals

Mechanism

Seccomp filters restrict system calls using a policy evaluated on syscall number, architecture, and arguments. A blocked command-execution syscall does not imply that all useful file or communication operations are blocked. Exploit planning should identify the actual allowed operations and the resources already available to the process.

Practical method

Inspect the filter or its construction code and list allow, deny, and default actions. Confirm architecture checks and argument restrictions. Inventory open file descriptors and mapped memory before choosing a goal. In a local fixture, trace the intended syscall sequence and find the first rejected operation.

# Trace only the isolated challenge and annotate denied calls.
strace -f -e trace=openat,read,write,execve ./challenge

Interpreting evidence

A process killed by a filter differs from a syscall returning an error. Preserve the filter action and error behavior in your notes. A read/write plan depends on accessible descriptors or permitted open operations.

Pitfalls and limits

Syscall numbers depend on ABI. libc wrappers may use a different syscall from the one their function name suggests. A filter inherited across child processes still applies unless the policy allows relevant changes.