1SECCOMP(2)                 Linux Programmer's Manual                SECCOMP(2)
2
3
4

NAME

6       seccomp - operate on Secure Computing state of the process
7

SYNOPSIS

9       #include <linux/seccomp.h>
10       #include <linux/filter.h>
11       #include <linux/audit.h>
12       #include <linux/signal.h>
13       #include <sys/ptrace.h>
14
15       int seccomp(unsigned int operation, unsigned int flags, void *args);
16

DESCRIPTION

18       The  seccomp()  system  call operates on the Secure Computing (seccomp)
19       state of the calling process.
20
21       Currently, Linux supports the following operation values:
22
23       SECCOMP_SET_MODE_STRICT
24              The only system calls that the calling thread  is  permitted  to
25              make  are  read(2),  write(2), _exit(2) (but not exit_group(2)),
26              and sigreturn(2).  Other system calls result in the delivery  of
27              a  SIGKILL  signal.   Strict secure computing mode is useful for
28              number-crunching applications that may need to execute untrusted
29              byte code, perhaps obtained by reading from a pipe or socket.
30
31              Note  that  although  the calling thread can no longer call sig‐
32              procmask(2), it can use sigreturn(2) to block all signals  apart
33              from  SIGKILL  and SIGSTOP.  This means that alarm(2) (for exam‐
34              ple) is not sufficient for restricting the  process's  execution
35              time.   Instead, to reliably terminate the process, SIGKILL must
36              be used.   This  can  be  done  by  using  timer_create(2)  with
37              SIGEV_SIGNAL  and  sigev_signo set to SIGKILL, or by using setr‐
38              limit(2) to set the hard limit for RLIMIT_CPU.
39
40              This operation is available only if  the  kernel  is  configured
41              with CONFIG_SECCOMP enabled.
42
43              The value of flags must be 0, and args must be NULL.
44
45              This operation is functionally identical to the call:
46
47                  prctl(PR_SET_SECCOMP, SECCOMP_MODE_STRICT);
48
49       SECCOMP_SET_MODE_FILTER
50              The  system calls allowed are defined by a pointer to a Berkeley
51              Packet Filter (BPF) passed via args.  This argument is a pointer
52              to  a  struct sock_fprog; it can be designed to filter arbitrary
53              system calls and  system  call  arguments.   If  the  filter  is
54              invalid, seccomp() fails, returning EINVAL in errno.
55
56              If  fork(2) or clone(2) is allowed by the filter, any child pro‐
57              cesses will be constrained to the same system  call  filters  as
58              the  parent.  If execve(2) is allowed, the existing filters will
59              be preserved across a call to execve(2).
60
61              In order to use the  SECCOMP_SET_MODE_FILTER  operation,  either
62              the calling thread must have the CAP_SYS_ADMIN capability in its
63              user namespace, or the thread must already have the no_new_privs
64              bit set.  If that bit was not already set by an ancestor of this
65              thread, the thread must make the following call:
66
67                  prctl(PR_SET_NO_NEW_PRIVS, 1);
68
69              Otherwise,  the  SECCOMP_SET_MODE_FILTER  operation  fails   and
70              returns  EACCES  in  errno.   This  requirement  ensures that an
71              unprivileged process cannot apply a malicious  filter  and  then
72              invoke   a   set-user-ID   or  other  privileged  program  using
73              execve(2), thus potentially compromising that program.  (Such  a
74              malicious  filter  might,  for  example, cause an attempt to use
75              setuid(2) to set the caller's user  IDs  to  nonzero  values  to
76              instead return 0 without actually making the system call.  Thus,
77              the program might be tricked into retaining superuser privileges
78              in circumstances where it is possible to influence it to do dan‐
79              gerous things because it did not actually drop privileges.)
80
81              If prctl(2) or seccomp() is allowed by the attached filter, fur‐
82              ther  filters may be added.  This will increase evaluation time,
83              but allows for further reduction of the  attack  surface  during
84              execution of a thread.
85
86              The  SECCOMP_SET_MODE_FILTER  operation is available only if the
87              kernel is configured with CONFIG_SECCOMP_FILTER enabled.
88
89              When flags is 0, this operation is functionally identical to the
90              call:
91
92                  prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, args);
93
94              The recognized flags are:
95
96              SECCOMP_FILTER_FLAG_TSYNC
97                     When  adding  a new filter, synchronize all other threads
98                     of the calling process to the same seccomp  filter  tree.
99                     A  "filter  tree" is the ordered list of filters attached
100                     to a thread.  (Attaching identical  filters  in  separate
101                     seccomp()  calls  results  in different filters from this
102                     perspective.)
103
104                     If any thread cannot synchronize to the same filter tree,
105                     the call will not attach the new seccomp filter, and will
106                     fail, returning the first thread  ID  found  that  cannot
107                     synchronize.  Synchronization will fail if another thread
108                     in the same process is in SECCOMP_MODE_STRICT  or  if  it
109                     has  attached  new  seccomp  filters to itself, diverging
110                     from the calling thread's filter tree.
111
112              SECCOMP_FILTER_FLAG_LOG (since Linux 4.14)
113                     All filter return actions except SECCOMP_RET_ALLOW should
114                     be  logged.   An  administrator  may override this filter
115                     flag by preventing specific actions from being logged via
116                     the /proc/sys/kernel/seccomp/actions_logged file.
117
118              SECCOMP_FILTER_FLAG_SPEC_ALLOW (since Linux 4.17)
119                     Disable Speculative Store Bypass mitigation.
120
121       SECCOMP_GET_ACTION_AVAIL (since Linux 4.14)
122              Test to see if an action is supported by the kernel.  This oper‐
123              ation is helpful to confirm that the  kernel  knows  of  a  more
124              recently  added filter return action since the kernel treats all
125              unknown actions as SECCOMP_RET_KILL_PROCESS.
126
127              The value of flags must be 0, and args must be a pointer  to  an
128              unsigned 32-bit filter return action.
129
130   Filters
131       When  adding filters via SECCOMP_SET_MODE_FILTER, args points to a fil‐
132       ter program:
133
134           struct sock_fprog {
135               unsigned short      len;    /* Number of BPF instructions */
136               struct sock_filter *filter; /* Pointer to array of
137                                              BPF instructions */
138           };
139
140       Each program must contain one or more BPF instructions:
141
142           struct sock_filter {            /* Filter block */
143               __u16 code;                 /* Actual filter code */
144               __u8  jt;                   /* Jump true */
145               __u8  jf;                   /* Jump false */
146               __u32 k;                    /* Generic multiuse field */
147           };
148
149       When executing the instructions, the BPF program operates on the system
150       call information made available (i.e., use the BPF_ABS addressing mode)
151       as a (read-only) buffer of the following form:
152
153           struct seccomp_data {
154               int   nr;                   /* System call number */
155               __u32 arch;                 /* AUDIT_ARCH_* value
156                                              (see <linux/audit.h>) */
157               __u64 instruction_pointer;  /* CPU instruction pointer */
158               __u64 args[6];              /* Up to 6 system call arguments */
159           };
160
161       Because numbering of system calls varies between architectures and some
162       architectures  (e.g.,  x86-64) allow user-space code to use the calling
163       conventions of multiple architectures (and the  convention  being  used
164       may  vary  over  the  life  of a process that uses execve(2) to execute
165       binaries that employ the different conventions), it is  usually  neces‐
166       sary to verify the value of the arch field.
167
168       It  is strongly recommended to use an allow-list approach whenever pos‐
169       sible because such an approach is more robust and simple.  A  deny-list
170       will have to be updated whenever a potentially dangerous system call is
171       added (or a dangerous flag or option if those are deny-listed), and  it
172       is often possible to alter the representation of a value without alter‐
173       ing its meaning, leading to  a  deny-list  bypass.   See  also  Caveats
174       below.
175
176       The  arch  field is not unique for all calling conventions.  The x86-64
177       ABI and the x32 ABI both use AUDIT_ARCH_X86_64 as arch, and they run on
178       the  same  processors.   Instead, the mask __X32_SYSCALL_BIT is used on
179       the system call number to tell the two ABIs apart.
180
181       This means that in order to create a seccomp-based deny-list for system
182       calls  performed  through  the  x86-64 ABI, it is necessary to not only
183       check that arch equals AUDIT_ARCH_X86_64, but also to explicitly reject
184       all system calls that contain __X32_SYSCALL_BIT in nr.
185
186       The  instruction_pointer field provides the address of the machine-lan‐
187       guage instruction that performed the system call.  This might be useful
188       in conjunction with the use of /proc/[pid]/maps to perform checks based
189       on which region (mapping) of the program made the system call.  (Proba‐
190       bly,  it  is wise to lock down the mmap(2) and mprotect(2) system calls
191       to prevent the program from subverting such checks.)
192
193       When checking values from args against a deny-list, keep in  mind  that
194       arguments  are  often  silently  truncated  before being processed, but
195       after the seccomp check.  For example, this happens if the i386 ABI  is
196       used  on  an  x86-64 kernel: although the kernel will normally not look
197       beyond the 32 lowest bits of the arguments,  the  values  of  the  full
198       64-bit  registers will be present in the seccomp data.  A less surpris‐
199       ing example is that if the x86-64 ABI is used to perform a system  call
200       that  takes  an  argument of type int, the more-significant half of the
201       argument register is ignored by the system call,  but  visible  in  the
202       seccomp data.
203
204       A  seccomp  filter  returns a 32-bit value consisting of two parts: the
205       most significant 16 bits (corresponding to the mask defined by the con‐
206       stant  SECCOMP_RET_ACTION_FULL)  contain  one  of  the  "action" values
207       listed below; the least significant 16-bits (defined  by  the  constant
208       SECCOMP_RET_DATA) are "data" to be associated with this return value.
209
210       If  multiple  filters exist, they are all executed, in reverse order of
211       their addition to the filter tree—that is, the most recently  installed
212       filter  is  executed first.  (Note that all filters will be called even
213       if one of the earlier filters returns SECCOMP_RET_KILL.  This  is  done
214       to  simplify the kernel code and to provide a tiny speed-up in the exe‐
215       cution of sets of filters by avoiding a check for this uncommon  case.)
216       The  return  value  for  the  evaluation  of a given system call is the
217       first-seen action value of highest precedence (along with its  accompa‐
218       nying data) returned by execution of all of the filters.
219
220       In  decreasing  order  of  precedence,  the  action  values that may be
221       returned by a seccomp filter are:
222
223       SECCOMP_RET_KILL_PROCESS (since Linux 4.14)
224              This value results in immediate termination of the process, with
225              a core dump.  The system call is not executed.  By contrast with
226              SECCOMP_RET_KILL_THREAD below, all threads in the  thread  group
227              are  terminated.   (For  a  discussion of thread groups, see the
228              description of the CLONE_THREAD flag in clone(2).)
229
230              The process terminates as though  killed  by  a  SIGSYS  signal.
231              Even  if  a  signal  handler has been registered for SIGSYS, the
232              handler will be ignored in this case and the process always ter‐
233              minates.   To  a  parent process that is waiting on this process
234              (using waitpid(2) or similar), the returned wstatus  will  indi‐
235              cate that its child was terminated as though by a SIGSYS signal.
236
237       SECCOMP_RET_KILL_THREAD (or SECCOMP_RET_KILL)
238              This  value  results in immediate termination of the thread that
239              made the system call.  The system call is not  executed.   Other
240              threads in the same thread group will continue to execute.
241
242              The  thread terminates as though killed by a SIGSYS signal.  See
243              SECCOMP_RET_KILL_PROCESS above.
244
245              Before Linux 4.11, any process terminated in this way would  not
246              trigger  a  coredump  (even  though SIGSYS is documented in sig‐
247              nal(7) as having a default action of  termination  with  a  core
248              dump).   Since  Linux  4.11, a single-threaded process will dump
249              core if terminated in this way.
250
251              With the addition of  SECCOMP_RET_KILL_PROCESS  in  Linux  4.14,
252              SECCOMP_RET_KILL_THREAD   was   added  as  a  synonym  for  SEC‐
253              COMP_RET_KILL, in order to  more  clearly  distinguish  the  two
254              actions.
255
256       SECCOMP_RET_TRAP
257              This  value  results  in  the  kernel  sending a thread-directed
258              SIGSYS signal to the triggering thread.  (The system call is not
259              executed.)   Various  fields will be set in the siginfo_t struc‐
260              ture (see sigaction(2)) associated with signal:
261
262              *  si_signo will contain SIGSYS.
263
264              *  si_call_addr  will  show  the  address  of  the  system  call
265                 instruction.
266
267              *  si_syscall  and  si_arch  will indicate which system call was
268                 attempted.
269
270              *  si_code will contain SYS_SECCOMP.
271
272              *  si_errno will contain the  SECCOMP_RET_DATA  portion  of  the
273                 filter return value.
274
275              The  program  counter will be as though the system call happened
276              (i.e., the program counter will not point  to  the  system  call
277              instruction).   The return value register will contain an archi‐
278              tecture-dependent value; if resuming execution, set it to  some‐
279              thing appropriate for the system call.  (The architecture depen‐
280              dency is because replacing it with ENOSYS could  overwrite  some
281              useful information.)
282
283       SECCOMP_RET_ERRNO
284              This  value  results in the SECCOMP_RET_DATA portion of the fil‐
285              ter's return value being passed to user space as the errno value
286              without executing the system call.
287
288       SECCOMP_RET_TRACE
289              When  returned,  this  value will cause the kernel to attempt to
290              notify a ptrace(2)-based tracer prior to  executing  the  system
291              call.   If  there  is  no tracer present, the system call is not
292              executed and returns a failure status with errno set to ENOSYS.
293
294              A tracer will be notified if it  requests  PTRACE_O_TRACESECCOMP
295              using ptrace(PTRACE_SETOPTIONS).  The tracer will be notified of
296              a PTRACE_EVENT_SECCOMP and the SECCOMP_RET_DATA portion  of  the
297              filter's  return  value  will  be  available  to  the tracer via
298              PTRACE_GETEVENTMSG.
299
300              The tracer can skip the system call by changing the system  call
301              number  to  -1.  Alternatively, the tracer can change the system
302              call requested by changing the system call  to  a  valid  system
303              call  number.   If the tracer asks to skip the system call, then
304              the system call will appear to return the value that the  tracer
305              puts in the return value register.
306
307              Before kernel 4.8, the seccomp check will not be run again after
308              the tracer is notified.  (This means  that,  on  older  kernels,
309              seccomp-based  sandboxes must not allow use of ptrace(2)—even of
310              other sandboxed processes—without extreme care; ptracers can use
311              this mechanism to escape from the seccomp sandbox.)
312
313       SECCOMP_RET_LOG (since Linux 4.14)
314              This  value  results in the system call being executed after the
315              filter return action is logged.  An administrator  may  override
316              the   logging  of  this  action  via  the  /proc/sys/kernel/sec‐
317              comp/actions_logged file.
318
319       SECCOMP_RET_ALLOW
320              This value results in the system call being executed.
321
322       If an action value other than one of the above is specified,  then  the
323       filter  action  is  treated  as  either SECCOMP_RET_KILL_PROCESS (since
324       Linux 4.14) or SECCOMP_RET_KILL_THREAD (in Linux 4.13 and earlier).
325
326   /proc interfaces
327       The files in the directory /proc/sys/kernel/seccomp provide  additional
328       seccomp information and configuration:
329
330       actions_avail (since Linux 4.14)
331              A  read-only  ordered  list  of seccomp filter return actions in
332              string form.  The ordering, from left-to-right, is in decreasing
333              order  of  precedence.   The  list represents the set of seccomp
334              filter return actions supported by the kernel.
335
336       actions_logged (since Linux 4.14)
337              A read-write ordered list of seccomp filter return actions  that
338              are  allowed to be logged.  Writes to the file do not need to be
339              in ordered form but reads from the file will be ordered  in  the
340              same way as the actions_avail file.
341
342              It  is  important  to note that the value of actions_logged does
343              not prevent certain filter return actions from being logged when
344              the  audit  subsystem  is  configured  to  audit a task.  If the
345              action is not found in the actions_logged file, the final  deci‐
346              sion  on whether to audit the action for that task is ultimately
347              left up to the audit subsystem to decide for all  filter  return
348              actions other than SECCOMP_RET_ALLOW.
349
350              The "allow" string is not accepted in the actions_logged file as
351              it is not possible to log SECCOMP_RET_ALLOW actions.  Attempting
352              to write "allow" to the file will fail with the error EINVAL.
353
354   Audit logging of seccomp actions
355       Since  Linux  4.14, the kernel provides the facility to log the actions
356       returned by seccomp filters in the audit log.   The  kernel  makes  the
357       decision to log an action based on the action type,  whether or not the
358       action is present in the actions_logged file, and whether kernel audit‐
359       ing  is  enabled (e.g., via the kernel boot option audit=1).  The rules
360       are as follows:
361
362       *  If the action is SECCOMP_RET_ALLOW, the action is not logged.
363
364       *  Otherwise, if the action is either SECCOMP_RET_KILL_PROCESS or  SEC‐
365          COMP_RET_KILL_THREAD,  and that action appears in the actions_logged
366          file, the action is logged.
367
368       *  Otherwise, if the filter has  requested  logging  (the  SECCOMP_FIL‐
369          TER_FLAG_LOG  flag)  and  the  action  appears in the actions_logged
370          file, the action is logged.
371
372       *  Otherwise, if kernel auditing is enabled and the  process  is  being
373          audited (autrace(8)), the action is logged.
374
375       *  Otherwise, the action is not logged.
376

RETURN VALUE

378       On   success,   seccomp()   returns   0.   On  error,  if  SECCOMP_FIL‐
379       TER_FLAG_TSYNC was used, the return value is the ID of the thread  that
380       caused  the synchronization failure.  (This ID is a kernel thread ID of
381       the type returned by clone(2) and gettid(2).)  On other errors,  -1  is
382       returned, and errno is set to indicate the cause of the error.
383

ERRORS

385       seccomp() can fail for the following reasons:
386
387       EACCES The caller did not have the CAP_SYS_ADMIN capability in its user
388              namespace,  or  had  not  set  no_new_privs  before  using  SEC‐
389              COMP_SET_MODE_FILTER.
390
391       EFAULT args was not a valid address.
392
393       EINVAL operation  is unknown or is not supported by this kernel version
394              or configuration.
395
396       EINVAL The specified flags are invalid for the given operation.
397
398       EINVAL operation included BPF_ABS, but the  specified  offset  was  not
399              aligned  to  a  32-bit  boundary  or exceeded sizeof(struct sec‐
400              comp_data).
401
402       EINVAL A secure computing mode has already been set, and operation dif‐
403              fers from the existing setting.
404
405       EINVAL operation specified SECCOMP_SET_MODE_FILTER, but the filter pro‐
406              gram pointed to by args was not valid or the length of the  fil‐
407              ter  program  was  zero or exceeded BPF_MAXINSNS (4096) instruc‐
408              tions.
409
410       ENOMEM Out of memory.
411
412       ENOMEM The total length of all filter programs attached to the  calling
413              thread  would  exceed  MAX_INSNS_PER_PATH  (32768) instructions.
414              Note that for the  purposes  of  calculating  this  limit,  each
415              already  existing filter program incurs an overhead penalty of 4
416              instructions.
417
418       EOPNOTSUPP
419              operation specified  SECCOMP_GET_ACTION_AVAIL,  but  the  kernel
420              does not support the filter return action specified by args.
421
422       ESRCH  Another  thread  caused a failure during thread sync, but its ID
423              could not be determined.
424

VERSIONS

426       The seccomp() system call first appeared in Linux 3.17.
427

CONFORMING TO

429       The seccomp() system call is a nonstandard Linux extension.
430

NOTES

432       Rather than hand-coding seccomp filters as shown in the example  below,
433       you  may  prefer  to  employ  the  libseccomp library, which provides a
434       front-end for generating seccomp filters.
435
436       The Seccomp field of the /proc/[pid]/status file provides a  method  of
437       viewing the seccomp mode of a process; see proc(5).
438
439       seccomp()  provides  a  superset  of  the functionality provided by the
440       prctl(2) PR_SET_SECCOMP operation (which does not support flags).
441
442       Since Linux 4.4, the ptrace(2) PTRACE_SECCOMP_GET_FILTER operation  can
443       be used to dump a process's seccomp filters.
444
445   Architecture support for seccomp BPF
446       Architecture support for seccomp BPF filtering is available on the fol‐
447       lowing architectures:
448
449       *  x86-64, i386, x32 (since Linux 3.5)
450       *  ARM (since Linux 3.8)
451       *  s390 (since Linux 3.8)
452       *  MIPS (since Linux 3.16)
453       *  ARM-64 (since Linux 3.19)
454       *  PowerPC (since Linux 4.3)
455       *  Tile (since Linux 4.3)
456       *  PA-RISC (since Linux 4.6)
457
458   Caveats
459       There are various subtleties to consider when applying seccomp  filters
460       to a program, including the following:
461
462       *  Some traditional system calls have user-space implementations in the
463          vdso(7) on many architectures.  Notable examples include  clock_get‐
464          time(2),  gettimeofday(2), and time(2).  On such architectures, sec‐
465          comp filtering for these system calls will have  no  effect.   (How‐
466          ever,  there  are  cases  where the vdso(7) implementations may fall
467          back to invoking the true system call, in which case seccomp filters
468          would see the system call.)
469
470       *  Seccomp  filtering is based on system call numbers.  However, appli‐
471          cations typically do not directly invoke system calls,  but  instead
472          call  wrapper  functions  in  the C library which in turn invoke the
473          system calls.  Consequently, one must be aware of the following:
474
475          ·  The glibc wrappers for some traditional system calls may actually
476             employ  system  calls  with  different  names in the kernel.  For
477             example,  the  exit(2)  wrapper  function  actually  employs  the
478             exit_group(2) system call, and the fork(2) wrapper function actu‐
479             ally calls clone(2).
480
481          ·  The behavior of wrapper functions may vary across  architectures,
482             according  to  the range of system calls provided on those archi‐
483             tectures.  In other words, the same wrapper function  may  invoke
484             different system calls on different architectures.
485
486          ·  Finally,  the  behavior  of  wrapper  functions can change across
487             glibc versions.  For example, in older versions, the glibc  wrap‐
488             per  function  for  open(2)  invoked  the system call of the same
489             name, but starting in glibc 2.26, the implementation switched  to
490             calling openat(2) on all architectures.
491
492       The consequence of the above points is that it may be necessary to fil‐
493       ter for a system call other than might  be  expected.   Various  manual
494       pages  in  Section  2  provide  helpful  details  about the differences
495       between wrapper functions and the underlying system  calls  in  subsec‐
496       tions entitled C library/kernel differences.
497
498       Furthermore,  note  that  the application of seccomp filters even risks
499       causing bugs in an application, when the filters cause unexpected fail‐
500       ures  for legitimate operations that the application might need to per‐
501       form.  Such bugs may not easily be discovered when testing the  seccomp
502       filters if the bugs occur in rarely used application code paths.
503
504   Seccomp-specific BPF details
505       Note the following BPF details specific to seccomp filters:
506
507       *  The BPF_H and BPF_B size modifiers are not supported: all operations
508          must load and store (4-byte) words (BPF_W).
509
510       *  To access the contents of the seccomp_data buffer, use  the  BPF_ABS
511          addressing mode modifier.
512
513       *  The  BPF_LEN addressing mode modifier yields an immediate mode oper‐
514          and whose value is the size of the seccomp_data buffer.
515

EXAMPLE

517       The program below accepts four or  more  arguments.   The  first  three
518       arguments  are a system call number, a numeric architecture identifier,
519       and an error number.  The program uses these values to construct a  BPF
520       filter that is used at run time to perform the following checks:
521
522       [1] If  the  program  is not running on the specified architecture, the
523           BPF filter causes system calls to fail with the error ENOSYS.
524
525       [2] If the program attempts to execute the system call with the  speci‐
526           fied  number,  the  BPF filter causes the system call to fail, with
527           errno being set to the specified error number.
528
529       The remaining command-line arguments specify  the  pathname  and  addi‐
530       tional  arguments  of a program that the example program should attempt
531       to  execute  using  execv(3)  (a  library  function  that  employs  the
532       execve(2)  system  call).   Some  example runs of the program are shown
533       below.
534
535       First, we display the architecture that we are running on (x86-64)  and
536       then  construct  a  shell function that looks up system call numbers on
537       this architecture:
538
539           $ uname -m
540           x86_64
541           $ syscall_nr() {
542               cat /usr/src/linux/arch/x86/syscalls/syscall_64.tbl | \
543               awk '$2 != "x32" && $3 == "'$1'" { print $1 }'
544           }
545
546       When the BPF filter rejects a system call (case [2] above),  it  causes
547       the  system call to fail with the error number specified on the command
548       line.  In the experiments shown here, we'll use error number 99:
549
550           $ errno 99
551           EADDRNOTAVAIL 99 Cannot assign requested address
552
553       In the following example, we attempt to run the command whoami(1),  but
554       the  BPF  filter rejects the execve(2) system call, so that the command
555       is not even executed:
556
557           $ syscall_nr execve
558           59
559           $ ./a.out
560           Usage: ./a.out <syscall_nr> <arch> <errno> <prog> [<args>]
561           Hint for <arch>: AUDIT_ARCH_I386: 0x40000003
562                            AUDIT_ARCH_X86_64: 0xC000003E
563           $ ./a.out 59 0xC000003E 99 /bin/whoami
564           execv: Cannot assign requested address
565
566       In the next example, the BPF filter rejects the write(2)  system  call,
567       so  that, although it is successfully started, the whoami(1) command is
568       not able to write output:
569
570           $ syscall_nr write
571           1
572           $ ./a.out 1 0xC000003E 99 /bin/whoami
573
574       In the final example, the BPF filter rejects a system call that is  not
575       used  by  the  whoami(1) command, so it is able to successfully execute
576       and produce output:
577
578           $ syscall_nr preadv
579           295
580           $ ./a.out 295 0xC000003E 99 /bin/whoami
581           cecilia
582
583   Program source
584       #include <errno.h>
585       #include <stddef.h>
586       #include <stdio.h>
587       #include <stdlib.h>
588       #include <unistd.h>
589       #include <linux/audit.h>
590       #include <linux/filter.h>
591       #include <linux/seccomp.h>
592       #include <sys/prctl.h>
593
594       #define X32_SYSCALL_BIT 0x40000000
595
596       static int
597       install_filter(int syscall_nr, int t_arch, int f_errno)
598       {
599           unsigned int upper_nr_limit = 0xffffffff;
600
601           /* Assume that AUDIT_ARCH_X86_64 means the normal x86-64 ABI
602              (in the x32 ABI, all system calls have bit 30 set in the
603              'nr' field, meaning the numbers are >= X32_SYSCALL_BIT) */
604           if (t_arch == AUDIT_ARCH_X86_64)
605               upper_nr_limit = X32_SYSCALL_BIT - 1;
606
607           struct sock_filter filter[] = {
608               /* [0] Load architecture from 'seccomp_data' buffer into
609                      accumulator */
610               BPF_STMT(BPF_LD | BPF_W | BPF_ABS,
611                        (offsetof(struct seccomp_data, arch))),
612
613               /* [1] Jump forward 5 instructions if architecture does not
614                      match 't_arch' */
615               BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, t_arch, 0, 5),
616
617               /* [2] Load system call number from 'seccomp_data' buffer into
618                      accumulator */
619               BPF_STMT(BPF_LD | BPF_W | BPF_ABS,
620                        (offsetof(struct seccomp_data, nr))),
621
622               /* [3] Check ABI - only needed for x86-64 in deny-list use
623                      cases.  Use BPF_JGT instead of checking against the bit
624                      mask to avoid having to reload the syscall number. */
625               BPF_JUMP(BPF_JMP | BPF_JGT | BPF_K, upper_nr_limit, 3, 0),
626
627               /* [4] Jump forward 1 instruction if system call number
628                      does not match 'syscall_nr' */
629               BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, syscall_nr, 0, 1),
630
631               /* [5] Matching architecture and system call: don't execute
632                   the system call, and return 'f_errno' in 'errno' */
633               BPF_STMT(BPF_RET | BPF_K,
634                        SECCOMP_RET_ERRNO | (f_errno & SECCOMP_RET_DATA)),
635
636               /* [6] Destination of system call number mismatch: allow other
637                      system calls */
638               BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ALLOW),
639
640               /* [7] Destination of architecture mismatch: kill task */
641               BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_KILL),
642           };
643
644           struct sock_fprog prog = {
645               .len = (unsigned short) (sizeof(filter) / sizeof(filter[0])),
646               .filter = filter,
647           };
648
649           if (seccomp(SECCOMP_SET_MODE_FILTER, 0, &prog)) {
650               perror("seccomp");
651               return 1;
652           }
653
654           return 0;
655       }
656
657       int
658       main(int argc, char **argv)
659       {
660           if (argc < 5) {
661               fprintf(stderr, "Usage: "
662                       "%s <syscall_nr> <arch> <errno> <prog> [<args>]\n"
663                       "Hint for <arch>: AUDIT_ARCH_I386: 0x%X\n"
664                       "                 AUDIT_ARCH_X86_64: 0x%X\n"
665                       "\n", argv[0], AUDIT_ARCH_I386, AUDIT_ARCH_X86_64);
666               exit(EXIT_FAILURE);
667           }
668
669           if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) {
670               perror("prctl");
671               exit(EXIT_FAILURE);
672           }
673
674           if (install_filter(strtol(argv[1], NULL, 0),
675                              strtol(argv[2], NULL, 0),
676                              strtol(argv[3], NULL, 0)))
677               exit(EXIT_FAILURE);
678
679           execv(argv[4], &argv[4]);
680           perror("execv");
681           exit(EXIT_FAILURE);
682       }
683

SEE ALSO

685       bpfc(1), strace(1), bpf(2), prctl(2), ptrace(2), sigaction(2), proc(5),
686       signal(7), socket(7)
687
688       Various    pages    from    the    libseccomp    library,    including:
689       scmp_sys_resolver(1),    seccomp_init(3),     seccomp_load(3),     sec‐
690       comp_rule_add(3), and seccomp_export_bpf(3).
691
692       The  kernel  source files Documentation/networking/filter.txt and Docu‐
693       mentation/userspace-api/seccomp_filter.rst (or Documentation/prctl/sec‐
694       comp_filter.txt before Linux 4.13).
695
696       McCanne, S. and Jacobson, V. (1992) The BSD Packet Filter: A New Archi‐
697       tecture for User-level Packet Capture, Proceedings of the USENIX Winter
698       1993 Conference ⟨http://www.tcpdump.org/papers/bpf-usenix93.pdf
699

COLOPHON

701       This  page  is  part of release 5.04 of the Linux man-pages project.  A
702       description of the project, information about reporting bugs,  and  the
703       latest     version     of     this    page,    can    be    found    at
704       https://www.kernel.org/doc/man-pages/.
705
706
707
708Linux                             2019-11-19                        SECCOMP(2)
Impressum