From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ozlabs.org (Postfix) with ESMTP id D3DACB6EFF for ; Sat, 14 May 2011 01:18:55 +1000 (EST) Subject: Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering From: Eric Paris To: Ingo Molnar Date: Fri, 13 May 2011 11:17:52 -0400 In-Reply-To: <20110513131800.GA7883@elte.hu> References: <20110512130104.GA2912@elte.hu> <20110513121034.GG21022@elte.hu> <1305289146.2466.8.camel@twins> <20110513122646.GA3924@elte.hu> <1305290370.2466.14.camel@twins> <1305290612.2466.17.camel@twins> <20110513125452.GD3924@elte.hu> <1305292132.2466.26.camel@twins> <20110513131800.GA7883@elte.hu> Content-Type: text/plain; charset="UTF-8" Message-ID: <1305299880.2076.31.camel@localhost.localdomain> Mime-Version: 1.0 Cc: linux-mips@linux-mips.org, linux-sh@vger.kernel.org, Peter Zijlstra , Frederic Weisbecker , Heiko Carstens , Oleg Nesterov , David Howells , Paul Mackerras , "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" , Steven Rostedt , Tejun Heo , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, Michal Marek , Michal Simek , Will Drewry , 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: , [dropping microblaze and roland] On Fri, 2011-05-13 at 15:18 +0200, Ingo Molnar wrote: > * Peter Zijlstra wrote: > > > On Fri, 2011-05-13 at 14:54 +0200, Ingo Molnar wrote: > > > I think the sanest semantics is to run all active callbacks as well. > > > > > > For example if this is used for three stacked security policies - as if 3 LSM > > > modules were stacked at once. We'd call all three, and we'd determine that at > > > least one failed - and we'd return a failure. > > > > But that only works for boolean functions where you can return the > > multi-bit-or of the result. What if you need to return the specific > > error code. > > Do you mean that one filter returns -EINVAL while the other -EACCES? > > Seems like a non-problem to me, we'd return the first nonzero value. Sounds so easy! Why haven't LSMs stacked already? Because what happens if one of these hooks did something stateful? Lets say on open, hook #1 returns EPERM. hook #2 allocates memory. The open is going to fail and hooks #2 is never going to get the close() which should have freed the allocation. If you can be completely stateless its easier, but there's a reason that stacking security modules is hard. Serge has tried in the past and both dhowells and casey schaufler are working on it right now. Stacking is never as easy as it sounds :) -Eric