[lkml]   [2011]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Patch in this message
    Subject[PATCH 5/7] seccomp_filter: Document what seccomp_filter is and how it works.
    Adds a text file covering what CONFIG_SECCOMP_FILTER is, how it is
    implemented presently, and what it may be used for. In addition,
    the limitations and caveats of the proposed implementation are

    Signed-off-by: Will Drewry <>
    Documentation/trace/seccomp_filter.txt | 75 ++++++++++++++++++++++++++++++++
    1 files changed, 75 insertions(+), 0 deletions(-)
    create mode 100644 Documentation/trace/seccomp_filter.txt

    diff --git a/Documentation/trace/seccomp_filter.txt b/Documentation/trace/seccomp_filter.txt
    new file mode 100644
    index 0000000..6a0fd33
    --- /dev/null
    +++ b/Documentation/trace/seccomp_filter.txt
    @@ -0,0 +1,75 @@
    + Seccomp filtering
    + =================
    +A large number of system calls are exposed to every userland process
    +with many of them going unused for the entire lifetime of the
    +application. As system calls change and mature, bugs are found and
    +quashed. A certain subset of userland applications benefit by having
    +a reduce set of available system calls. The reduced set reduces the
    +total kernel surface exposed to the application. System call filtering
    +is meant for use with those applications.
    +The implementation currently leverages both the existing seccomp
    +infrastructure and the kernel tracing infrastructure. By centralizing
    +hooks for attack surface reduction in seccomp, it is possible to assure
    +attention to security that is less relevant in normal ftrace scenarios,
    +such as time of check, time of use attacks. However, ftrace provides a
    +rich, human-friendly environment for specifying system calls by name and
    +expected arguments. (As such, this requires FTRACE_SYSCALLS.)
    +What it isn't
    +System call filtering isn't a sandbox. It provides a clearly defined
    +mechanism for minimizing the exposed kernel surface. Beyond that, policy for
    +logical behavior and information flow should be managed with an LSM of your
    +An additional seccomp mode is exposed through mode '2'. This mode
    +depends on CONFIG_SECCOMP_FILTER which in turn depends on
    +A collection of filters may be supplied via prctl, and the current set of
    +filters is exposed in /proc/<pid>/seccomp_filter.
    +For instance,
    + const char filters[] =
    + "sys_read: (fd == 1) || (fd == 2)\n"
    + "sys_write: (fd == 0)\n"
    + "sys_exit: 1\n"
    + "sys_exit_group: 1\n"
    + "on_next_syscall: 1";
    + prctl(PR_SET_SECCOMP, 2, filters);
    +This will setup system call filters for read, write, and exit where reading can
    +be done only from fds 1 and 2 and writing to fd 0. The "on_next_syscall" directive tells
    +seccomp to not enforce the ruleset until after the next system call is run. This allows
    +for launchers to apply system call filters to a binary before executing it.
    +Once enabled, the access may only be reduced. For example, a set of filters may be:
    + sys_read: 1
    + sys_write: 1
    + sys_mmap: 1
    + sys_prctl: 1
    +Then it may call the following to drop mmap access:
    + prctl(PR_SET_SECCOMP, 2, "sys_mmap: 0");
    +The system call names come from ftrace events. At present, many system
    +calls are not hooked - such as x86's ptregs wrapped system calls.
    +In addition compat_task()s will not be supported until a sys32s begin
    +being hooked.

     \ /
      Last update: 2011-04-28 05:13    [W:0.032 / U:2.136 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site