lkml.org 
[lkml]   [2012]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF
    On Thu, Jan 12, 2012 at 8:27 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
    > On Thu, 2012-01-12 at 08:14 -0800, Andrew Lutomirski wrote:
    >
    >> The longer I linger on lists and see neat ideas like this, the more I
    >> get annoyed that execve is magical.  I dream of a distribution that
    >> doesn't use setuid, file capabilities, selinux transitions on exec, or
    >> any other privilege changes on exec *at all*.
    >
    > Is that the fear with filtering on execv? That if we have filters on an
    > execv calling a setuid program that we change the behavior of that
    > privileged program and might cause unexpected results?

    Exactly.

    >
    > In that case, just have execv fail if filtering is enabled and we are
    > execing a setuid program. But I don't see why non "magical" execv's
    > should be prohibited.
    >

    How do you define "non-magical"?

    If setuid is set, then it's obviously magical. On a nosuid
    filesystem, strange things happen. If file capabilities are enabled
    and set, then different magic happens. With LSMs involved, anything
    can be magical. (SELinux AFAICT looks up rules on every single exec,
    so it might be impossible for execve to be non-magical.) If execve is
    banned entirely when seccomp is enabled, then there will never be any
    attacks based on abusing these mechanisms.

    My proposal is to have an alternative mechanism that, from a security
    POV, does nothing that the caller couldn't have done on its own. The
    only reason it would be needed at all is because implementing execve
    with correct semantics from userspace is a PITA -- the right set of
    fds needs to be closed, threads need to be killed (without races),
    vmas need to be found an unmapped, a new program needs to be mapped in
    (possibly at the same place that the old one was mapped at),
    /proc/self/exe needs to be updated, auxv needs to be recreated
    (including using values that glibc might have erased already), etc.

    The code is short and it works (although I have no idea whether it
    applies to current kernels).

    Oleg: my only issue with setting something like LSM_UNSAFE_SECCOMP is
    that a different class of vulnerability might be introduced: take a
    setuid program that calls other setuid programs (or just uses execve
    as a way to get the default execve capability handling, SELinux
    handling, etc), run it (as root!) inside seccomp, and watch it
    possibly develop security holes. If the alternate execve is a
    different syscall, then this can't happen. And if someone remaps
    execve to execve_nosecurity (from userspace or via some in-kernel
    mechanism) and causes problems, it's entirely clear who to blame.

    --Andy
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2012-01-12 17:55    [W:4.843 / U:0.316 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site