Compare commits

...

2 Commits

Author SHA1 Message Date
Michael Kerrisk ae6b221882 prctl.2: Rewrite the description of PR_SET_SECCOMP to defer to seccomp(2)
There is a lot of unnecessary duplication of content of the seccomp
material in prctl(2) and seccomp(2).  Trevor Woerner also noted that
there is an error in prctl(2), where it says that the filters
"are run in order until the first non-allow result is seen", which
contradicts the correct statement in seccomp(2) that *all* filters
are executed.

So, rewrite the seccomp material in prctl(2) to strip out most of
the content duplicated in seccomp(2), and replace the removed
text with statements deferring to to seccomp(2).

Reported-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2021-09-02 00:15:52 +02:00
Michael Kerrisk 2da936fe2b prctl.2: Note that seccomp(2) is preferred over prctl(2) for setting seccomp mode
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2021-09-01 23:57:17 +02:00
1 changed files with 24 additions and 47 deletions

View File

@ -1135,72 +1135,48 @@ the available system calls.
The more recent
.BR seccomp (2)
system call provides a superset of the functionality of
.BR PR_SET_SECCOMP .
.BR PR_SET_SECCOMP ,
and is the preferred interface for new applications.
.IP
The seccomp mode is selected via
.IR arg2 .
(The seccomp constants are defined in
.IR <linux/seccomp.h> .)
The following values can be specified:
.RS
.TP
.BR SECCOMP_MODE_STRICT " (since Linux 2.6.23)"
See the description of
.B SECCOMP_SET_MODE_STRICT
in
.BR seccomp (2).
.IP
With
.IR arg2
set to
.BR SECCOMP_MODE_STRICT ,
the only system calls that the thread is permitted to make are
.BR read (2),
.BR write (2),
.BR _exit (2)
(but not
.BR exit_group (2)),
and
.BR sigreturn (2).
Other system calls result in the delivery of a
.BR SIGKILL
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.
This operation is available only
if the kernel is configured with
.B CONFIG_SECCOMP
enabled.
.IP
With
.IR arg2
set to
.BR SECCOMP_MODE_FILTER " (since Linux 3.5),"
the system calls allowed are defined by a pointer
.TP
.BR SECCOMP_MODE_FILTER " (since Linux 3.5)"
The allowed system calls are defined by a pointer
to a Berkeley Packet Filter passed in
.IR arg3 .
This argument is a pointer to
.IR "struct sock_fprog" ;
it can be designed to filter
arbitrary system calls and system call arguments.
This mode is available only if the kernel is configured with
See the description of
.B SECCOMP_SET_MODE_FILTER
in
.BR seccomp (2).
.IP
This operation is available only
if the kernel is configured with
.B CONFIG_SECCOMP_FILTER
enabled.
.RE
.IP
If
.BR SECCOMP_MODE_FILTER
filters permit
.BR fork (2),
then the seccomp mode is inherited by children created by
.BR fork (2);
if
.BR execve (2)
is permitted, then the seccomp mode is preserved across
.BR execve (2).
If the filters permit
.BR prctl ()
calls, then additional filters can be added;
they are run in order until the first non-allow result is seen.
.IP
For further information, see the kernel source file
.IR Documentation/userspace\-api/seccomp_filter.rst
.\" commit c061f33f35be0ccc80f4b8e0aea5dfd2ed7e01a3
(or
.IR Documentation/prctl/seccomp_filter.txt
before Linux 4.13).
For further details on seccomp filtering, see
.BR seccomp (2).
.\" prctl PR_GET_SECCOMP
.TP
.BR PR_GET_SECCOMP " (since Linux 2.6.23)"
@ -1216,6 +1192,7 @@ If the caller is in filter mode, and this system call is allowed by the
seccomp filters, it returns 2; otherwise, the process is killed with a
.BR SIGKILL
signal.
.IP
This operation is available only
if the kernel is configured with
.B CONFIG_SECCOMP