lkml.org 
[lkml]   [2012]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: Compat 32-bit syscall entry from 64-bit task!? [was: Re: [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF]
    From
    On Wed, January 18, 2012 06:43, Chris Evans wrote:
    >> As far as I know, we fixed all races except symlink races caused by malicious
    >> code outside the jail.
    >
    > Are you sure? I've remembered possibly the worst one I encountered,
    > since my previous e-mail to Jamie:
    >
    > 1) Tracee is compromised; executes fork() which is syscall that isn't allowed

    How do you mean compromised? Tracees aren't trusted by definition. And fork is
    allowed in our jail, we're ptracing all tasks within the jail.

    > 2) Tracee traps
    > 2b) Tracee could take a SIGKILL here
    > 3) Tracer looks at registers; bad syscall
    > 3b) Or tracee could take a SIGKILL here
    > 4) The only way to stop the bad syscall from executing is to rewrite
    > orig_eax (PTRACE_CONT + SIGKILL only kills the process after the
    > syscall has finished)

    Yes, we rewrite it to -1.

    > 5) Disaster: the tracee took a SIGKILL so any attempt to address it by
    > pid (such as PTRACE_SETREGS) fails.

    I assume that if a task can execute system calls and we get ptrace events
    for that, that we can do other ptrace operations too. Are you saying that
    the kernel has this ptrace gap between SIGKILL and task exit where ptrace
    doesn't work but the task continues executing system calls? That would be
    a huge bug, but it seems very unlikely too, as the task is stopped and
    shouldn't be able to disappear till it is continued by the tracer.

    I mean, really? That would be stupid.

    If true we have to work around it by disallowing SIGKILL and just sending
    them ourselves within the jail. Meh.

    > 6) Syscall fork() executes; possible unsupervised process now running
    > since the tracer wasn't expecting the fork() to be allowed.

    We use PTRACE_O_TRACEFORK (or replace it with clone and set CLONE_PTRACE
    for 2.4 kernels. Yes, I check for CLONE_UNTRACED in clone calls.)

    >
    > All this ptrace() security headache is why vsftpd is waiting for
    > Will's seccomp enhancements to hit the kernel. Then they will be used
    > pronto.

    How will you avoid file path races with BPF?

    Greetings,

    Indan




    \
     
     \ /
      Last update: 2012-01-18 13:15    [W:4.271 / U:0.084 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site