Rather than hand-coding seccomp filters as shown in the example
below, you may prefer to employ the libseccomp library, which
provides a front-end for generating seccomp filters.
The Seccomp field of the /proc/[pid]/status file provides a
method of viewing the seccomp mode of a process; see proc(5).
seccomp() provides a superset of the functionality provided by
the prctl(2) PR_SET_SECCOMP operation (which does not support
flags).
Since Linux 4.4, the ptrace(2) PTRACE_SECCOMP_GET_FILTER
operation can be used to dump a process's seccomp filters.
Architecture support for seccomp BPF
Architecture support for seccomp BPF filtering is available on
the following architectures:
* x86-64, i386, x32 (since Linux 3.5)
* ARM (since Linux 3.8)
* s390 (since Linux 3.8)
* MIPS (since Linux 3.16)
* ARM-64 (since Linux 3.19)
* PowerPC (since Linux 4.3)
* Tile (since Linux 4.3)
* PA-RISC (since Linux 4.6)
Caveats
There are various subtleties to consider when applying seccomp
filters to a program, including the following:
* Some traditional system calls have user-space implementations
in the vdso(7) on many architectures. Notable examples
include clock_gettime(2), gettimeofday(2), and time(2). On
such architectures, seccomp filtering for these system calls
will have no effect. (However, there are cases where the
vdso(7) implementations may fall back to invoking the true
system call, in which case seccomp filters would see the
system call.)
* Seccomp filtering is based on system call numbers. However,
applications typically do not directly invoke system calls,
but instead call wrapper functions in the C library which in
turn invoke the system calls. Consequently, one must be aware
of the following:
• The glibc wrappers for some traditional system calls may
actually employ system calls with different names in the
kernel. For example, the exit(2) wrapper function actually
employs the exit_group(2) system call, and the fork(2)
wrapper function actually calls clone(2).
• The behavior of wrapper functions may vary across
architectures, according to the range of system calls
provided on those architectures. In other words, the same
wrapper function may invoke different system calls on
different architectures.
• Finally, the behavior of wrapper functions can change
across glibc versions. For example, in older versions, the
glibc wrapper function for open(2) invoked the system call
of the same name, but starting in glibc 2.26, the
implementation switched to calling openat(2) on all
architectures.
The consequence of the above points is that it may be necessary
to filter for a system call other than might be expected.
Various manual pages in Section 2 provide helpful details about
the differences between wrapper functions and the underlying
system calls in subsections entitled C library/kernel
differences.
Furthermore, note that the application of seccomp filters even
risks causing bugs in an application, when the filters cause
unexpected failures for legitimate operations that the
application might need to perform. Such bugs may not easily be
discovered when testing the seccomp filters if the bugs occur in
rarely used application code paths.
Seccomp-specific BPF details
Note the following BPF details specific to seccomp filters:
* The BPF_H and BPF_B size modifiers are not supported: all
operations must load and store (4-byte) words (BPF_W).
* To access the contents of the seccomp_data buffer, use the
BPF_ABS addressing mode modifier.
* The BPF_LEN addressing mode modifier yields an immediate mode
operand whose value is the size of the seccomp_data buffer.
