-
Notifications
You must be signed in to change notification settings - Fork 0
/
seccomp.html
1421 lines (1093 loc) · 43.4 KB
/
seccomp.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!-- Creator : groff version 1.22.4 -->
<!-- CreationDate: Wed Jan 29 11:26:51 2020 -->
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta name="generator" content="groff -Thtml, see www.gnu.org">
<meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">
<meta name="Content-Style" content="text/css">
<style type="text/css">
p { margin-top: 0; margin-bottom: 0; vertical-align: top }
pre { margin-top: 0; margin-bottom: 0; vertical-align: top }
table { margin-top: 0; margin-bottom: 0; vertical-align: top }
h1 { text-align: center }
</style>
<title>SECCOMP</title>
</head>
<body>
<h1 align="center">SECCOMP</h1>
<a href="#NAME">NAME</a><br>
<a href="#SYNOPSIS">SYNOPSIS</a><br>
<a href="#DESCRIPTION">DESCRIPTION</a><br>
<a href="#RETURN VALUE">RETURN VALUE</a><br>
<a href="#ERRORS">ERRORS</a><br>
<a href="#VERSIONS">VERSIONS</a><br>
<a href="#CONFORMING TO">CONFORMING TO</a><br>
<a href="#NOTES">NOTES</a><br>
<a href="#EXAMPLE">EXAMPLE</a><br>
<a href="#SEE ALSO">SEE ALSO</a><br>
<a href="#COLOPHON">COLOPHON</a><br>
<hr>
<h2>NAME
<a name="NAME"></a>
</h2>
<p style="margin-left:11%; margin-top: 1em">seccomp -
operate on Secure Computing state of the process</p>
<h2>SYNOPSIS
<a name="SYNOPSIS"></a>
</h2>
<p style="margin-left:11%; margin-top: 1em"><b>#include
<linux/seccomp.h> <br>
#include <linux/filter.h> <br>
#include <linux/audit.h> <br>
#include <linux/signal.h> <br>
#include <sys/ptrace.h></b></p>
<p style="margin-left:11%; margin-top: 1em"><b>int
seccomp(unsigned int</b> <i>operation</i><b>, unsigned
int</b> <i>flags</i><b>, void *</b><i>args</i><b>);</b></p>
<h2>DESCRIPTION
<a name="DESCRIPTION"></a>
</h2>
<p style="margin-left:11%; margin-top: 1em">The
<b>seccomp</b>() system call operates on the Secure
Computing (seccomp) state of the calling process.</p>
<p style="margin-left:11%; margin-top: 1em">Currently,
Linux supports the following <i>operation</i> values:
<b><br>
SECCOMP_SET_MODE_STRICT</b></p>
<p style="margin-left:22%;">The only system calls that the
calling thread is permitted to make are <b>read</b>(2),
<b>write</b>(2), <b>_exit</b>(2) (but not
<b>exit_group</b>(2)), and <b>sigreturn</b>(2). Other system
calls result in the delivery of a <b>SIGKILL</b> signal.
Strict secure computing mode is useful for number-crunching
applications that may need to execute untrusted byte code,
perhaps obtained by reading from a pipe or socket.</p>
<p style="margin-left:22%; margin-top: 1em">Note that
although the calling thread can no longer call
<b>sigprocmask</b>(2), it can use <b>sigreturn</b>(2) to
block all signals apart from <b>SIGKILL</b> and
<b>SIGSTOP</b>. This means that <b>alarm</b>(2) (for
example) is not sufficient for restricting the
process’s execution time. Instead, to reliably
terminate the process, <b>SIGKILL</b> must be used. This can
be done by using <b>timer_create</b>(2) with
<b>SIGEV_SIGNAL</b> and <i>sigev_signo</i> set to
<b>SIGKILL</b>, or by using <b>setrlimit</b>(2) to set the
hard limit for <b>RLIMIT_CPU</b>.</p>
<p style="margin-left:22%; margin-top: 1em">This operation
is available only if the kernel is configured with
<b>CONFIG_SECCOMP</b> enabled.</p>
<p style="margin-left:22%; margin-top: 1em">The value of
<i>flags</i> must be 0, and <i>args</i> must be NULL.</p>
<p style="margin-left:22%; margin-top: 1em">This operation
is functionally identical to the call:</p>
<p style="margin-left:28%; margin-top: 1em">prctl(PR_SET_SECCOMP,
SECCOMP_MODE_STRICT);</p>
<p style="margin-left:11%;"><b>SECCOMP_SET_MODE_FILTER</b></p>
<p style="margin-left:22%;">The system calls allowed are
defined by a pointer to a Berkeley Packet Filter (BPF)
passed via <i>args</i>. This argument is a pointer to a
<i>struct sock_fprog</i>; it can be designed to filter
arbitrary system calls and system call arguments. If the
filter is invalid, <b>seccomp</b>() fails, returning
<b>EINVAL</b> in <i>errno</i>.</p>
<p style="margin-left:22%; margin-top: 1em">If
<b>fork</b>(2) or <b>clone</b>(2) is allowed by the filter,
any child processes will be constrained to the same system
call filters as the parent. If <b>execve</b>(2) is allowed,
the existing filters will be preserved across a call to
<b>execve</b>(2).</p>
<p style="margin-left:22%; margin-top: 1em">In order to use
the <b>SECCOMP_SET_MODE_FILTER</b> operation, either the
calling thread must have the <b>CAP_SYS_ADMIN</b> capability
in its user namespace, or the thread must already have the
<i>no_new_privs</i> bit set. If that bit was not already set
by an ancestor of this thread, the thread must make the
following call:</p>
<p style="margin-left:28%; margin-top: 1em">prctl(PR_SET_NO_NEW_PRIVS,
1);</p>
<p style="margin-left:22%; margin-top: 1em">Otherwise, the
<b>SECCOMP_SET_MODE_FILTER</b> operation fails and returns
<b>EACCES</b> in <i>errno</i>. This requirement ensures that
an unprivileged process cannot apply a malicious filter and
then invoke a set-user-ID or other privileged program using
<b>execve</b>(2), thus potentially compromising that
program. (Such a malicious filter might, for example, cause
an attempt to use <b>setuid</b>(2) to set the caller’s
user IDs to nonzero values to instead return 0 without
actually making the system call. Thus, the program might be
tricked into retaining superuser privileges in circumstances
where it is possible to influence it to do dangerous things
because it did not actually drop privileges.)</p>
<p style="margin-left:22%; margin-top: 1em">If
<b>prctl</b>(2) or <b>seccomp</b>() is allowed by the
attached filter, further filters may be added. This will
increase evaluation time, but allows for further reduction
of the attack surface during execution of a thread.</p>
<p style="margin-left:22%; margin-top: 1em">The
<b>SECCOMP_SET_MODE_FILTER</b> operation is available only
if the kernel is configured with
<b>CONFIG_SECCOMP_FILTER</b> enabled.</p>
<p style="margin-left:22%; margin-top: 1em">When
<i>flags</i> is 0, this operation is functionally identical
to the call:</p>
<p style="margin-left:28%; margin-top: 1em">prctl(PR_SET_SECCOMP,
SECCOMP_MODE_FILTER, args);</p>
<p style="margin-left:22%; margin-top: 1em">The recognized
<i>flags</i> are: <b><br>
SECCOMP_FILTER_FLAG_TSYNC</b></p>
<p style="margin-left:32%;">When adding a new filter,
synchronize all other threads of the calling process to the
same seccomp filter tree. A "filter tree" is the
ordered list of filters attached to a thread. (Attaching
identical filters in separate <b>seccomp</b>() calls results
in different filters from this perspective.)</p>
<p style="margin-left:32%; margin-top: 1em">If any thread
cannot synchronize to the same filter tree, the call will
not attach the new seccomp filter, and will fail, returning
the first thread ID found that cannot synchronize.
Synchronization will fail if another thread in the same
process is in <b>SECCOMP_MODE_STRICT</b> or if it has
attached new seccomp filters to itself, diverging from the
calling thread’s filter tree.</p>
<p style="margin-left:22%;"><b>SECCOMP_FILTER_FLAG_LOG</b>
(since Linux 4.14)</p>
<p style="margin-left:32%;">All filter return actions
except <b>SECCOMP_RET_ALLOW</b> should be logged. An
administrator may override this filter flag by preventing
specific actions from being logged via the
<i>/proc/sys/kernel/seccomp/actions_logged</i> file.</p>
<p style="margin-left:22%;"><b>SECCOMP_FILTER_FLAG_SPEC_ALLOW</b>
(since Linux 4.17)</p>
<p style="margin-left:32%;">Disable Speculative Store
Bypass mitigation.</p>
<p style="margin-left:11%;"><b>SECCOMP_GET_ACTION_AVAIL</b>
(since Linux 4.14)</p>
<p style="margin-left:22%;">Test to see if an action is
supported by the kernel. This operation is helpful to
confirm that the kernel knows of a more recently added
filter return action since the kernel treats all unknown
actions as <b>SECCOMP_RET_KILL_PROCESS</b>.</p>
<p style="margin-left:22%; margin-top: 1em">The value of
<i>flags</i> must be 0, and <i>args</i> must be a pointer to
an unsigned 32-bit filter return action.</p>
<p style="margin-left:11%; margin-top: 1em"><b>Filters</b>
<br>
When adding filters via <b>SECCOMP_SET_MODE_FILTER</b>,
<i>args</i> points to a filter program:</p>
<p style="margin-left:17%; margin-top: 1em">struct
sock_fprog { <br>
unsigned short len; /* Number of BPF instructions */ <br>
struct sock_filter *filter; /* Pointer to array of <br>
BPF instructions */ <br>
};</p>
<p style="margin-left:11%; margin-top: 1em">Each program
must contain one or more BPF instructions:</p>
<p style="margin-left:17%; margin-top: 1em">struct
sock_filter { /* Filter block */ <br>
__u16 code; /* Actual filter code */ <br>
__u8 jt; /* Jump true */ <br>
__u8 jf; /* Jump false */ <br>
__u32 k; /* Generic multiuse field */ <br>
};</p>
<p style="margin-left:11%; margin-top: 1em">When executing
the instructions, the BPF program operates on the system
call information made available (i.e., use the
<b>BPF_ABS</b> addressing mode) as a (read-only) buffer of
the following form:</p>
<p style="margin-left:17%; margin-top: 1em">struct
seccomp_data { <br>
int nr; /* System call number */ <br>
__u32 arch; /* AUDIT_ARCH_* value <br>
(see <linux/audit.h>) */ <br>
__u64 instruction_pointer; /* CPU instruction pointer */
<br>
__u64 args[6]; /* Up to 6 system call arguments */ <br>
};</p>
<p style="margin-left:11%; margin-top: 1em">Because
numbering of system calls varies between architectures and
some architectures (e.g., x86-64) allow user-space code to
use the calling conventions of multiple architectures (and
the convention being used may vary over the life of a
process that uses <b>execve</b>(2) to execute binaries that
employ the different conventions), it is usually necessary
to verify the value of the <i>arch</i> field.</p>
<p style="margin-left:11%; margin-top: 1em">It is strongly
recommended to use a whitelisting approach whenever possible
because such an approach is more robust and simple. A
blacklist will have to be updated whenever a potentially
dangerous system call is added (or a dangerous flag or
option if those are blacklisted), and it is often possible
to alter the representation of a value without altering its
meaning, leading to a blacklist bypass. See also
<i>Caveats</i> below.</p>
<p style="margin-left:11%; margin-top: 1em">The <i>arch</i>
field is not unique for all calling conventions. The x86-64
ABI and the x32 ABI both use <b>AUDIT_ARCH_X86_64</b> as
<i>arch</i>, and they run on the same processors. Instead,
the mask <b>__X32_SYSCALL_BIT</b> is used on the system call
number to tell the two ABIs apart.</p>
<p style="margin-left:11%; margin-top: 1em">This means that
in order to create a seccomp-based blacklist for system
calls performed through the x86-64 ABI, it is necessary to
not only check that <i>arch</i> equals
<b>AUDIT_ARCH_X86_64</b>, but also to explicitly reject all
system calls that contain <b>__X32_SYSCALL_BIT</b> in
<i>nr</i>.</p>
<p style="margin-left:11%; margin-top: 1em">The
<i>instruction_pointer</i> field provides the address of the
machine-language instruction that performed the system call.
This might be useful in conjunction with the use of
<i>/proc/[pid]/maps</i> to perform checks based on which
region (mapping) of the program made the system call.
(Probably, it is wise to lock down the <b>mmap</b>(2) and
<b>mprotect</b>(2) system calls to prevent the program from
subverting such checks.)</p>
<p style="margin-left:11%; margin-top: 1em">When checking
values from <i>args</i> against a blacklist, keep in mind
that arguments are often silently truncated before being
processed, but after the seccomp check. For example, this
happens if the i386 ABI is used on an x86-64 kernel:
although the kernel will normally not look beyond the 32
lowest bits of the arguments, the values of the full 64-bit
registers will be present in the seccomp data. A less
surprising example is that if the x86-64 ABI is used to
perform a system call that takes an argument of type
<i>int</i>, the more-significant half of the argument
register is ignored by the system call, but visible in the
seccomp data.</p>
<p style="margin-left:11%; margin-top: 1em">A seccomp
filter returns a 32-bit value consisting of two parts: the
most significant 16 bits (corresponding to the mask defined
by the constant <b>SECCOMP_RET_ACTION_FULL</b>) contain one
of the "action" values listed below; the least
significant 16-bits (defined by the constant
<b>SECCOMP_RET_DATA</b>) are "data" to be
associated with this return value.</p>
<p style="margin-left:11%; margin-top: 1em">If multiple
filters exist, they are <i>all</i> executed, in reverse
order of their addition to the filter tree—that is,
the most recently installed filter is executed first. (Note
that all filters will be called even if one of the earlier
filters returns <b>SECCOMP_RET_KILL</b>. This is done to
simplify the kernel code and to provide a tiny speed-up in
the execution of sets of filters by avoiding a check for
this uncommon case.) The return value for the evaluation of
a given system call is the first-seen action value of
highest precedence (along with its accompanying data)
returned by execution of all of the filters.</p>
<p style="margin-left:11%; margin-top: 1em">In decreasing
order of precedence, the action values that may be returned
by a seccomp filter are: <b><br>
SECCOMP_RET_KILL_PROCESS</b> (since Linux 4.14)</p>
<p style="margin-left:22%;">This value results in immediate
termination of the process, with a core dump. The system
call is not executed. By contrast with
<b>SECCOMP_RET_KILL_THREAD</b> below, all threads in the
thread group are terminated. (For a discussion of thread
groups, see the description of the <b>CLONE_THREAD</b> flag
in <b>clone</b>(2).)</p>
<p style="margin-left:22%; margin-top: 1em">The process
terminates <i>as though</i> killed by a <b>SIGSYS</b>
signal. Even if a signal handler has been registered for
<b>SIGSYS</b>, the handler will be ignored in this case and
the process always terminates. To a parent process that is
waiting on this process (using <b>waitpid</b>(2) or
similar), the returned <i>wstatus</i> will indicate that its
child was terminated as though by a <b>SIGSYS</b>
signal.</p>
<p style="margin-left:11%;"><b>SECCOMP_RET_KILL_THREAD</b>
(or <b>SECCOMP_RET_KILL</b>)</p>
<p style="margin-left:22%;">This value results in immediate
termination of the thread that made the system call. The
system call is not executed. Other threads in the same
thread group will continue to execute.</p>
<p style="margin-left:22%; margin-top: 1em">The thread
terminates <i>as though</i> killed by a <b>SIGSYS</b>
signal. See <b>SECCOMP_RET_KILL_PROCESS</b> above.</p>
<p style="margin-left:22%; margin-top: 1em">Before Linux
4.11, any process terminated in this way would not trigger a
coredump (even though <b>SIGSYS</b> is documented in
<b>signal</b>(7) as having a default action of termination
with a core dump). Since Linux 4.11, a single-threaded
process will dump core if terminated in this way.</p>
<p style="margin-left:22%; margin-top: 1em">With the
addition of <b>SECCOMP_RET_KILL_PROCESS</b> in Linux 4.14,
<b>SECCOMP_RET_KILL_THREAD</b> was added as a synonym for
<b>SECCOMP_RET_KILL</b>, in order to more clearly
distinguish the two actions.</p>
<p style="margin-left:11%;"><b>SECCOMP_RET_TRAP</b></p>
<p style="margin-left:22%;">This value results in the
kernel sending a thread-directed <b>SIGSYS</b> signal to the
triggering thread. (The system call is not executed.)
Various fields will be set in the <i>siginfo_t</i> structure
(see <b>sigaction</b>(2)) associated with signal:</p>
<table width="100%" border="0" rules="none" frame="void"
cellspacing="0" cellpadding="0">
<tr valign="top" align="left">
<td width="22%"></td>
<td width="1%">
<p>*</p></td>
<td width="3%"></td>
<td width="74%">
<p><i>si_signo</i> will contain <b>SIGSYS</b>.</p></td></tr>
<tr valign="top" align="left">
<td width="22%"></td>
<td width="1%">
<p>*</p></td>
<td width="3%"></td>
<td width="74%">
<p><i>si_call_addr</i> will show the address of the system
call instruction.</p></td></tr>
<tr valign="top" align="left">
<td width="22%"></td>
<td width="1%">
<p>*</p></td>
<td width="3%"></td>
<td width="74%">
<p><i>si_syscall</i> and <i>si_arch</i> will indicate which
system call was attempted.</p></td></tr>
<tr valign="top" align="left">
<td width="22%"></td>
<td width="1%">
<p>*</p></td>
<td width="3%"></td>
<td width="74%">
<p><i>si_code</i> will contain <b>SYS_SECCOMP</b>.</p></td></tr>
<tr valign="top" align="left">
<td width="22%"></td>
<td width="1%">
<p>*</p></td>
<td width="3%"></td>
<td width="74%">
<p><i>si_errno</i> will contain the <b>SECCOMP_RET_DATA</b>
portion of the filter return value.</p></td></tr>
</table>
<p style="margin-left:22%; margin-top: 1em">The program
counter will be as though the system call happened (i.e.,
the program counter will not point to the system call
instruction). The return value register will contain an
architecture-dependent value; if resuming execution, set it
to something appropriate for the system call. (The
architecture dependency is because replacing it with
<b>ENOSYS</b> could overwrite some useful information.)</p>
<p style="margin-left:11%;"><b>SECCOMP_RET_ERRNO</b></p>
<p style="margin-left:22%;">This value results in the
<b>SECCOMP_RET_DATA</b> portion of the filter’s return
value being passed to user space as the <i>errno</i> value
without executing the system call.</p>
<p style="margin-left:11%;"><b>SECCOMP_RET_TRACE</b></p>
<p style="margin-left:22%;">When returned, this value will
cause the kernel to attempt to notify a
<b>ptrace</b>(2)-based tracer prior to executing the system
call. If there is no tracer present, the system call is not
executed and returns a failure status with <i>errno</i> set
to <b>ENOSYS</b>.</p>
<p style="margin-left:22%; margin-top: 1em">A tracer will
be notified if it requests <b>PTRACE_O_TRACESECCOMP</b>
using <i>ptrace(PTRACE_SETOPTIONS)</i>. The tracer will be
notified of a <b>PTRACE_EVENT_SECCOMP</b> and the
<b>SECCOMP_RET_DATA</b> portion of the filter’s return
value will be available to the tracer via
<b>PTRACE_GETEVENTMSG</b>.</p>
<p style="margin-left:22%; margin-top: 1em">The tracer can
skip the system call by changing the system call number to
-1. Alternatively, the tracer can change the system call
requested by changing the system call to a valid system call
number. If the tracer asks to skip the system call, then the
system call will appear to return the value that the tracer
puts in the return value register.</p>
<p style="margin-left:22%; margin-top: 1em">Before kernel
4.8, the seccomp check will not be run again after the
tracer is notified. (This means that, on older kernels,
seccomp-based sandboxes <b>must not</b> allow use of
<b>ptrace</b>(2)—even of other sandboxed
processes—without extreme care; ptracers can use this
mechanism to escape from the seccomp sandbox.)</p>
<p style="margin-left:11%;"><b>SECCOMP_RET_LOG</b> (since
Linux 4.14)</p>
<p style="margin-left:22%;">This value results in the
system call being executed after the filter return action is
logged. An administrator may override the logging of this
action via the
<i>/proc/sys/kernel/seccomp/actions_logged</i> file.</p>
<p style="margin-left:11%;"><b>SECCOMP_RET_ALLOW</b></p>
<p style="margin-left:22%;">This value results in the
system call being executed.</p>
<p style="margin-left:11%; margin-top: 1em">If an action
value other than one of the above is specified, then the
filter action is treated as either
<b>SECCOMP_RET_KILL_PROCESS</b> (since Linux 4.14) or
<b>SECCOMP_RET_KILL_THREAD</b> (in Linux 4.13 and
earlier).</p>
<p style="margin-left:11%; margin-top: 1em"><b>/proc
interfaces</b> <br>
The files in the directory <i>/proc/sys/kernel/seccomp</i>
provide additional seccomp information and configuration:
<i><br>
actions_avail</i> (since Linux 4.14)</p>
<p style="margin-left:22%;">A read-only ordered list of
seccomp filter return actions in string form. The ordering,
from left-to-right, is in decreasing order of precedence.
The list represents the set of seccomp filter return actions
supported by the kernel.</p>
<p style="margin-left:11%;"><i>actions_logged</i> (since
Linux 4.14)</p>
<p style="margin-left:22%;">A read-write ordered list of
seccomp filter return actions that are allowed to be logged.
Writes to the file do not need to be in ordered form but
reads from the file will be ordered in the same way as the
<i>actions_avail</i> file.</p>
<p style="margin-left:22%; margin-top: 1em">It is important
to note that the value of <i>actions_logged</i> does not
prevent certain filter return actions from being logged when
the audit subsystem is configured to audit a task. If the
action is not found in the <i>actions_logged</i> file, the
final decision on whether to audit the action for that task
is ultimately left up to the audit subsystem to decide for
all filter return actions other than
<b>SECCOMP_RET_ALLOW</b>.</p>
<p style="margin-left:22%; margin-top: 1em">The
"allow" string is not accepted in the
<i>actions_logged</i> file as it is not possible to log
<b>SECCOMP_RET_ALLOW</b> actions. Attempting to write
"allow" to the file will fail with the error
<b>EINVAL</b>.</p>
<p style="margin-left:11%; margin-top: 1em"><b>Audit
logging of seccomp actions</b> <br>
Since Linux 4.14, the kernel provides the facility to log
the actions returned by seccomp filters in the audit log.
The kernel makes the decision to log an action based on the
action type, whether or not the action is present in the
<i>actions_logged</i> file, and whether kernel auditing is
enabled (e.g., via the kernel boot option <i>audit=1</i>).
The rules are as follows:</p>
<table width="100%" border="0" rules="none" frame="void"
cellspacing="0" cellpadding="0">
<tr valign="top" align="left">
<td width="11%"></td>
<td width="1%">
<p>*</p></td>
<td width="3%"></td>
<td width="85%">
<p>If the action is <b>SECCOMP_RET_ALLOW</b>, the action is
not logged.</p></td></tr>
<tr valign="top" align="left">
<td width="11%"></td>
<td width="1%">
<p>*</p></td>
<td width="3%"></td>
<td width="85%">
<p>Otherwise, if the action is either
<b>SECCOMP_RET_KILL_PROCESS</b> or
<b>SECCOMP_RET_KILL_THREAD</b>, and that action appears in
the <i>actions_logged</i> file, the action is logged.</p></td></tr>
<tr valign="top" align="left">
<td width="11%"></td>
<td width="1%">
<p>*</p></td>
<td width="3%"></td>
<td width="85%">
<p>Otherwise, if the filter has requested logging (the
<b>SECCOMP_FILTER_FLAG_LOG</b> flag) and the action appears
in the <i>actions_logged</i> file, the action is logged.</p></td></tr>
<tr valign="top" align="left">
<td width="11%"></td>
<td width="1%">
<p>*</p></td>
<td width="3%"></td>
<td width="85%">
<p>Otherwise, if kernel auditing is enabled and the process
is being audited (<b>autrace</b>(8)), the action is
logged.</p> </td></tr>
<tr valign="top" align="left">
<td width="11%"></td>
<td width="1%">
<p>*</p></td>
<td width="3%"></td>
<td width="85%">
<p>Otherwise, the action is not logged.</p></td></tr>
</table>
<h2>RETURN VALUE
<a name="RETURN VALUE"></a>
</h2>
<p style="margin-left:11%; margin-top: 1em">On success,
<b>seccomp</b>() returns 0. On error, if
<b>SECCOMP_FILTER_FLAG_TSYNC</b> was used, the return value
is the ID of the thread that caused the synchronization
failure. (This ID is a kernel thread ID of the type returned
by <b>clone</b>(2) and <b>gettid</b>(2).) On other errors,
-1 is returned, and <i>errno</i> is set to indicate the
cause of the error.</p>
<h2>ERRORS
<a name="ERRORS"></a>
</h2>
<p style="margin-left:11%; margin-top: 1em"><b>seccomp</b>()
can fail for the following reasons:</p>
<table width="100%" border="0" rules="none" frame="void"
cellspacing="0" cellpadding="0">
<tr valign="top" align="left">
<td width="11%"></td>
<td width="9%">
<p style="margin-top: 1em"><b>EACCES</b></p></td>
<td width="2%"></td>
<td width="78%">
<p style="margin-top: 1em">The caller did not have the
<b>CAP_SYS_ADMIN</b> capability in its user namespace, or
had not set <i>no_new_privs</i> before using
<b>SECCOMP_SET_MODE_FILTER</b>.</p> </td></tr>
<tr valign="top" align="left">
<td width="11%"></td>
<td width="9%">
<p><b>EFAULT</b></p></td>
<td width="2%"></td>
<td width="78%">
<p><i>args</i> was not a valid address.</p></td></tr>
<tr valign="top" align="left">
<td width="11%"></td>
<td width="9%">
<p><b>EINVAL</b></p></td>
<td width="2%"></td>
<td width="78%">
<p><i>operation</i> is unknown or is not supported by this
kernel version or configuration.</p></td></tr>
<tr valign="top" align="left">
<td width="11%"></td>
<td width="9%">
<p><b>EINVAL</b></p></td>
<td width="2%"></td>
<td width="78%">
<p>The specified <i>flags</i> are invalid for the given
<i>operation</i>.</p> </td></tr>
<tr valign="top" align="left">
<td width="11%"></td>
<td width="9%">
<p><b>EINVAL</b></p></td>
<td width="2%"></td>
<td width="78%">
<p><i>operation</i> included <b>BPF_ABS</b>, but the
specified offset was not aligned to a 32-bit boundary or
exceeded <i>sizeof(struct seccomp_data)</i>.</p></td></tr>
<tr valign="top" align="left">
<td width="11%"></td>
<td width="9%">
<p><b>EINVAL</b></p></td>
<td width="2%"></td>
<td width="78%">
<p>A secure computing mode has already been set, and
<i>operation</i> differs from the existing setting.</p></td></tr>
<tr valign="top" align="left">
<td width="11%"></td>
<td width="9%">
<p><b>EINVAL</b></p></td>
<td width="2%"></td>
<td width="78%">
<p><i>operation</i> specified
<b>SECCOMP_SET_MODE_FILTER</b>, but the filter program
pointed to by <i>args</i> was not valid or the length of the
filter program was zero or exceeded <b>BPF_MAXINSNS</b>
(4096) instructions.</p></td></tr>
<tr valign="top" align="left">
<td width="11%"></td>
<td width="9%">
<p><b>ENOMEM</b></p></td>
<td width="2%"></td>
<td width="78%">
<p>Out of memory.</p></td></tr>
<tr valign="top" align="left">
<td width="11%"></td>
<td width="9%">
<p><b>ENOMEM</b></p></td>
<td width="2%"></td>
<td width="78%">
<p>The total length of all filter programs attached to the
calling thread would exceed <b>MAX_INSNS_PER_PATH</b>
(32768) instructions. Note that for the purposes of
calculating this limit, each already existing filter program
incurs an overhead penalty of 4 instructions.</p></td></tr>
</table>
<p style="margin-left:11%;"><b>EOPNOTSUPP</b></p>
<p style="margin-left:22%;"><i>operation</i> specified
<b>SECCOMP_GET_ACTION_AVAIL</b>, but the kernel does not
support the filter return action specified by
<i>args</i>.</p>
<table width="100%" border="0" rules="none" frame="void"
cellspacing="0" cellpadding="0">
<tr valign="top" align="left">
<td width="11%"></td>
<td width="7%">
<p><b>ESRCH</b></p></td>
<td width="4%"></td>
<td width="78%">
<p>Another thread caused a failure during thread sync, but
its ID could not be determined.</p></td></tr>
</table>
<h2>VERSIONS
<a name="VERSIONS"></a>
</h2>
<p style="margin-left:11%; margin-top: 1em">The
<b>seccomp</b>() system call first appeared in Linux
3.17.</p>
<h2>CONFORMING TO
<a name="CONFORMING TO"></a>
</h2>
<p style="margin-left:11%; margin-top: 1em">The
<b>seccomp</b>() system call is a nonstandard Linux
extension.</p>
<h2>NOTES
<a name="NOTES"></a>
</h2>
<p style="margin-left:11%; margin-top: 1em">Rather than
hand-coding seccomp filters as shown in the example below,
you may prefer to employ the <i>libseccomp</i> library,
which provides a front-end for generating seccomp
filters.</p>
<p style="margin-left:11%; margin-top: 1em">The
<i>Seccomp</i> field of the <i>/proc/[pid]/status</i> file
provides a method of viewing the seccomp mode of a process;
see <b>proc</b>(5).</p>
<p style="margin-left:11%; margin-top: 1em"><b>seccomp</b>()
provides a superset of the functionality provided by the
<b>prctl</b>(2) <b>PR_SET_SECCOMP</b> operation (which does
not support <i>flags</i>).</p>
<p style="margin-left:11%; margin-top: 1em">Since Linux
4.4, the <b>ptrace</b>(2) <b>PTRACE_SECCOMP_GET_FILTER</b>
operation can be used to dump a process’s seccomp
filters.</p>
<p style="margin-left:11%; margin-top: 1em"><b>Architecture
support for seccomp BPF</b> <br>
Architecture support for seccomp BPF filtering is available
on the following architectures:</p>
<table width="100%" border="0" rules="none" frame="void"
cellspacing="0" cellpadding="0">
<tr valign="top" align="left">
<td width="11%"></td>
<td width="1%">
<p style="margin-top: 1em">*</p></td>
<td width="3%"></td>
<td width="54%">
<p style="margin-top: 1em">x86-64, i386, x32 (since Linux
3.5)</p> </td>
<td width="31%">
</td></tr>
<tr valign="top" align="left">
<td width="11%"></td>
<td width="1%">
<p>*</p></td>
<td width="3%"></td>
<td width="54%">
<p>ARM (since Linux 3.8)</p></td>
<td width="31%">
</td></tr>
<tr valign="top" align="left">
<td width="11%"></td>
<td width="1%">
<p>*</p></td>
<td width="3%"></td>
<td width="54%">
<p>s390 (since Linux 3.8)</p></td>
<td width="31%">
</td></tr>
<tr valign="top" align="left">
<td width="11%"></td>
<td width="1%">
<p>*</p></td>
<td width="3%"></td>
<td width="54%">
<p>MIPS (since Linux 3.16)</p></td>
<td width="31%">
</td></tr>
<tr valign="top" align="left">
<td width="11%"></td>
<td width="1%">
<p>*</p></td>
<td width="3%"></td>
<td width="54%">
<p>ARM-64 (since Linux 3.19)</p></td>
<td width="31%">
</td></tr>
<tr valign="top" align="left">
<td width="11%"></td>
<td width="1%">
<p>*</p></td>
<td width="3%"></td>
<td width="54%">
<p>PowerPC (since Linux 4.3)</p></td>
<td width="31%">
</td></tr>
<tr valign="top" align="left">
<td width="11%"></td>
<td width="1%">
<p>*</p></td>
<td width="3%"></td>
<td width="54%">
<p>Tile (since Linux 4.3)</p></td>
<td width="31%">
</td></tr>
<tr valign="top" align="left">
<td width="11%"></td>
<td width="1%">
<p>*</p></td>
<td width="3%"></td>
<td width="54%">
<p>PA-RISC (since Linux 4.6)</p></td>
<td width="31%">
</td></tr>
</table>
<p style="margin-left:11%; margin-top: 1em"><b>Caveats</b>
<br>
There are various subtleties to consider when applying
seccomp filters to a program, including the following:</p>
<table width="100%" border="0" rules="none" frame="void"
cellspacing="0" cellpadding="0">
<tr valign="top" align="left">
<td width="11%"></td>
<td width="1%">
<p style="margin-top: 1em">*</p></td>
<td width="3%"></td>
<td width="85%">
<p style="margin-top: 1em">Some traditional system calls
have user-space implementations in the <b>vdso</b>(7) on
many architectures. Notable examples include
<b>clock_gettime</b>(2), <b>gettimeofday</b>(2), and
<b>time</b>(2). On such architectures, seccomp filtering for
these system calls will have no effect. (However, there are
cases where the <b>vdso</b>(7) implementations may fall back
to invoking the true system call, in which case seccomp
filters would see the system call.)</p></td></tr>
<tr valign="top" align="left">
<td width="11%"></td>