Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755049Ab2BOUC0 (ORCPT ); Wed, 15 Feb 2012 15:02:26 -0500 Received: from mail-bk0-f46.google.com ([209.85.214.46]:61265 "EHLO mail-bk0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751251Ab2BOUCZ (ORCPT ); Wed, 15 Feb 2012 15:02:25 -0500 Date: Wed, 15 Feb 2012 23:57:33 +0400 From: Vasiliy Kulikov To: Cyrill Gorcunov Cc: Oleg Nesterov , "Eric W. Biederman" , Pavel Emelyanov , Andrey Vagin , KOSAKI Motohiro , Ingo Molnar , "H. Peter Anvin" , Thomas Gleixner , Glauber Costa , Andi Kleen , Tejun Heo , Matt Helsley , Pekka Enberg , Eric Dumazet , Alexey Dobriyan , Valdis.Kletnieks@vt.edu, Michal Marek , Frederic Weisbecker , Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: + syscalls-x86-add-__nr_kcmp-syscall-v8.patch added to -mm tree Message-ID: <20120215195733.GA8021@albatros> References: <20120215143606.GA14037@redhat.com> <20120215151008.GL1894@moon> <20120215153816.GA15988@redhat.com> <20120215161329.GM1894@moon> <20120215162222.GA18266@redhat.com> <20120215175319.GG4533@moon> <20120215184336.GA24182@redhat.com> <20120215195610.GJ4533@moon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120215195610.GJ4533@moon> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1442 Lines: 36 On Wed, Feb 15, 2012 at 23:56 +0400, Cyrill Gorcunov wrote: > On Wed, Feb 15, 2012 at 07:43:36PM +0100, Oleg Nesterov wrote: > ... > > > > Cough... this is question I am trying to ask ;) > > > > Let me try again. To simplify, lets discuss the KCMP_VM case > > only. > > > > I do not really understand why do we need ptrace_may_access(). > > I do not see any security problems with kcmp_ptr(task->mm), but > > I am not expert. > > > > However, you added this check so I assume you have some reason. > > But this can race with execve(setuid_app) and KCMP_VM can play > > with task->mm after this task raises its caps. If this is fine, > > then why do we need ptrace_may_access? > > > > This makes me scratch the head ;) I think ptrace_may_access (or > some other security test) should remain since it's somehow weird > if non-root task will be able to find objects order from privileged > task. Thus I need to find a way how to handle execve(setuid_app). > Need to think... Look at fs/proc/base.c:lock_trace() - it locks ->cred_guard_mutex for the whole period of time when it uses a resource. -- Vasiliy Kulikov http://www.openwall.com - bringing security into open computing environments -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/