[lkml]   [2012]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC PATCH 0/3] move the secure_computing call
    On Thu, May 24, 2012 20:07, Roland McGrath wrote:
    > On Thu, May 24, 2012 at 9:13 AM, H. Peter Anvin <> wrote:
    >> I think this really screws with using seccomp for self-interception. I
    >> wouldn't inherently be opposed to the following flow:
    >> seccomp -> ptrace -> seccomp
    >> ... i.e. if ptrace is enabled and we enable something, run it through
    >> seccomp again, but there are bunch of use cases (mostly involving
    >> SIGSYS) where doing ptrace before seccomp is just bizarre.
    > Are you sure? This is ptrace syscall tracing going first.
    > If seccomp generates a SIGSYS, then ptrace will still get its opportunity
    > to intercept the signal and change the register state however it likes.

    If so, then the seccomp check needs to be redone after any ptrace
    changes, or we should give up and just do the seccomp check first,
    instead of possibly looping forever. PTRACE_EVENT_SECCOMP has the
    same problem.

    If a seccomp filtered task can do ptrace(), it can easily bypass
    the seccomp filter by ptracing any task not under the same filter
    but from the same user. And then it can puppeteer the victim into
    doing anything it wishes. So pretending seccomp can make a ptracer
    secure is futile, I think. Perhaps it's better to keep it simple and
    always do the seccomp test first and ignore ptrace changes, however
    sad that may seem. Seccomp had the power to stop ptrace(). It didn't,
    so it shouldn't try to do it afterwards either.

    It's a bit fuzzy though, only reason why doing seccomp first is more
    convenient is because seccomp can generate ptrace events. I don't
    think it will make a difference in practice because ptrace(2) won't
    be allowed by seccomp filters anyway, so it's a bit of a theoretical



     \ /
      Last update: 2012-05-24 21:21    [W:0.038 / U:3.276 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site