From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tundra.namei.org (tundra.namei.org [65.99.196.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id BA599B6EDF for ; Mon, 16 May 2011 10:37:44 +1000 (EST) Date: Mon, 16 May 2011 10:36:05 +1000 (EST) From: James Morris To: Ingo Molnar Subject: Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering In-Reply-To: <20110513121034.GG21022@elte.hu> Message-ID: References: <1304017638.18763.205.camel@gandalf.stny.rr.com> <1305169376-2363-1-git-send-email-wad@chromium.org> <20110512074850.GA9937@elte.hu> <20110512130104.GA2912@elte.hu> <20110513121034.GG21022@elte.hu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, 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 , 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: , On Fri, 13 May 2011, Ingo Molnar wrote: > Say i'm a user-space sandbox developer who wants to enforce that sandboxed code > should only be allowed to open files in /home/sandbox/, /lib/ and /usr/lib/. > > It is a simple and sensible security feature, agreed? It allows most code to > run well and link to countless libraries - but no access to other files is > allowed. Not really. Firstly, what is the security goal of these restrictions? Then, are the restrictions complete and unbypassable? How do you reason about the behavior of the system as a whole? > I argue that this is the LSM and audit subsystems designed right: in the long > run it could allow everything that LSM does at the moment - and so much more > ... Now you're proposing a redesign of the security subsystem. That's a significant undertaking. In the meantime, we have a simple, well-defined enhancement to seccomp which will be very useful to current users in reducing their kernel attack surface. We should merge that, and the security subsystem discussion can carry on separately. - James -- James Morris