[lkml]   [2009]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
    On Wed, May 6, 2009 at 14:29, Ingo Molnar <> wrote:
    > That's a pretty interesting usage. What would be fallback mode you
    > are using if the kernel doesnt have seccomp built in? Completely
    > non-sandboxed? Or a ptrace/PTRACE_SYSCALL based sandbox?

    Ptrace has performance and/or reliability problems when used to
    sandbox threaded applications due to potential race conditions when
    inspecting system call arguments. We hope that we can avoid this
    problem with seccomp. It is very attractive that kernel automatically
    terminates any application that violates the very well-defined
    constraints of the sandbox.

    In general, we are currently exploring different options based on
    general availability, functionality, and complexity of implementation.
    Seccomp is a good middle ground that we expect to be able to use in
    the medium term to provide an acceptable solution for a large segment
    of Linux users. Although the restriction to just four unfiltered
    system calls is painful.

    We are still discussing what fallback options we have, and they are
    likely on different schedules.

    For instance, on platforms that have AppArmor or SELinux, we might be
    able to use them as part of our sandboxing solution. Although we are
    still investigating whether they meet all of our needs.


     \ /
      Last update: 2009-05-06 23:49    [W:0.022 / U:0.084 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site