From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.mail.elte.hu (mx2.mail.elte.hu [157.181.151.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 5CE3FB6EF7 for ; Tue, 17 May 2011 22:57:35 +1000 (EST) Date: Tue, 17 May 2011 14:57:00 +0200 From: Ingo Molnar To: Will Drewry Subject: Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering Message-ID: <20110517125700.GD21441@elte.hu> References: <20110512074850.GA9937@elte.hu> <20110512130104.GA2912@elte.hu> <20110513121034.GG21022@elte.hu> <1305299455.2076.26.camel@localhost.localdomain> <20110514073015.GB9307@elte.hu> <20110516124304.GC7128@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Cc: linux-mips@linux-mips.org, linux-sh@vger.kernel.org, Peter Zijlstra , Frederic Weisbecker , Heiko Carstens , Oleg Nesterov , David Howells , Paul Mackerras , Eric Paris , "H. Peter Anvin" , sparclinux@vger.kernel.org, Jiri Slaby , linux-s390@vger.kernel.org, Russell King , x86@kernel.org, James Morris , Linus Torvalds , Ingo Molnar , kees.cook@canonical.com, "Serge E. Hallyn" , Peter Zijlstra , Steven Rostedt , Tejun Heo , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, Michal Marek , Michal Simek , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Ralf Baechle , Paul Mundt , Martin Schwidefsky , linux390@de.ibm.com, Andrew Morton , agl@chromium.org, "David S. Miller" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , * Will Drewry wrote: > > This is *far* more generic still yields the same short-term end result as > > far as your sandboxing is concerned. > > Almost :/ [...] Hey that's a pretty good result from a subsystem that was not written with your usecase in mind *at all* ;-) > [...] I still need to review the code you've pointed out, but, at present, > the ftrace hooks occur after the seccomp and syscall auditing hooks. This > means that that code is exposed no matter what in this model. To trim the > exposed surface to userspace, we really need those early hooks. While I can > see both hacky and less hacky approaches around this, it stills strikes me > that the seccomp thread flag and early interception are good to reuse. One > option might be to allow seccomp to be a secure-syscall event source, but I > suspect that lands more on the hack-y side of the fence :) Agreed, there should be no security compromise imposed on your usecase, at all. You could move the event callback sooner into the syscall-entry sequence to make sure it's the highest priority thing to process? There's no semantic dependency on its current location so this can be changed AFAICS. Thanks, Ingo