Re: Compat 32-bit syscall entry from 64-bit task!? [was: Re: [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF]

["Indan Zupancic" <indan@nul.nu>]

On Wed, January 18, 2012 22:13, Chris Evans wrote:
> On Wed, Jan 18, 2012 at 4:12 AM, Indan Zupancic <indan@nul.nu> wrote:
>> On Wed, January 18, 2012 06:43, Chris Evans wrote:
>>> 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.

Okay, I tested this scenario and you're right, we're screwed.

What the hell guys? What about other PID checks in the kernel, are they still
safe if the process looks dead but is still active? Or is it a ptrace-only
problem?

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

I guess this helps a bit. It doesn't prevent external signals, but prisoners
don't have control over that.

Is this SIGKILL specific or is it true for all task ending signals?

>> How will you avoid file path races with BPF?
>
> There is typically no need for file-path based access control in an FTP server.
> Take for example anonymous FTP, which will typically be inside a
> chroot() to /var/ftp. Inside that filesystem tree -- if you can open()
> it, you can have it.

Ah, you count on having root access. We don't.

Do you know any more crazy security destroying holes?

Thanks,

Indan