From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755601Ab2ASAOx (ORCPT ); Wed, 18 Jan 2012 19:14:53 -0500 Received: from smarthost1.greenhost.nl ([195.190.28.78]:38897 "EHLO smarthost1.greenhost.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753675Ab2ASAOv (ORCPT ); Wed, 18 Jan 2012 19:14:51 -0500 Message-ID: <54555afe915a79f7e77ee0f44ee6cb67.squirrel@webmail.greenhost.nl> In-Reply-To: References: <20120116183730.GB21112@redhat.com> <20120117164523.GA17070@redhat.com> <20120117170512.GB17070@redhat.com> <49017bd7edab7010cd9ac767e39d99e4.squirrel@webmail.greenhost.nl> <20120118015013.GR11715@one.firstfloor.org> <20120118020453.GL7180@jl-vm1.vm.bytemark.co.uk> <20120118022217.GS11715@one.firstfloor.org> Date: Thu, 19 Jan 2012 01:14:24 +0100 Subject: Re: Compat 32-bit syscall entry from 64-bit task!? [was: Re: [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF] From: "Indan Zupancic" To: "Chris Evans" Cc: "Andi Kleen" , "Jamie Lokier" , "Andrew Lutomirski" , "Oleg Nesterov" , "Will Drewry" , linux-kernel@vger.kernel.org, keescook@chromium.org, john.johansen@canonical.com, serge.hallyn@canonical.com, coreyb@linux.vnet.ibm.com, pmoore@redhat.com, eparis@redhat.com, djm@mindrot.org, torvalds@linux-foundation.org, segoon@openwall.com, rostedt@goodmis.org, jmorris@namei.org, avi@redhat.com, penberg@cs.helsinki.fi, viro@zeniv.linux.org.uk, mingo@elte.hu, akpm@linux-foundation.org, khilman@ti.com, borislav.petkov@amd.com, amwang@redhat.com, ak@linux.intel.com, eric.dumazet@gmail.com, gregkh@suse.de, dhowells@redhat.com, daniel.lezcano@free.fr, linux-fsdevel@vger.kernel.org, linux-security-module@vger.kernel.org, olofj@chromium.org, mhalcrow@google.com, dlaor@redhat.com, "Roland McGrath" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 1.4 X-Scan-Signature: 0cb660a7d4ce909c6359c48b0bded22a Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, January 18, 2012 22:13, Chris Evans wrote: > On Wed, Jan 18, 2012 at 4:12 AM, Indan Zupancic 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