From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753635Ab2ARMNP (ORCPT ); Wed, 18 Jan 2012 07:13:15 -0500 Received: from smarthost1.greenhost.nl ([195.190.28.78]:52543 "EHLO smarthost1.greenhost.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751915Ab2ARMNM (ORCPT ); Wed, 18 Jan 2012 07:13:12 -0500 Message-ID: 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: Wed, 18 Jan 2012 13:12:42 +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 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