From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 May 2011 13:49:11 +0200 (CEST) Received: from tundra.namei.org ([65.99.196.166]:51179 "EHLO tundra.namei.org" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S1491164Ab1ELLtE (ORCPT ); Thu, 12 May 2011 13:49:04 +0200 Received: from localhost (localhost [127.0.0.1]) by tundra.namei.org (8.13.1/8.13.1) with ESMTP id p4CBiGhI031727; Thu, 12 May 2011 07:44:16 -0400 Date: Thu, 12 May 2011 21:44:15 +1000 (EST) From: James Morris To: Ingo Molnar cc: Will Drewry , linux-kernel@vger.kernel.org, Steven Rostedt , Frederic Weisbecker , Eric Paris , kees.cook@canonical.com, agl@chromium.org, Peter Zijlstra , "Serge E. Hallyn" , Ingo Molnar , Andrew Morton , Tejun Heo , Michal Marek , Oleg Nesterov , Roland McGrath , Jiri Slaby , David Howells , Russell King , Michal Simek , Ralf Baechle , Benjamin Herrenschmidt , Paul Mackerras , Martin Schwidefsky , Heiko Carstens , linux390@de.ibm.com, Paul Mundt , "David S. Miller" , Thomas Gleixner , "H. Peter Anvin" , x86@kernel.org, Peter Zijlstra , linux-arm-kernel@lists.infradead.org, microblaze-uclinux@itee.uq.edu.au, linux-mips@linux-mips.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, Linus Torvalds Subject: Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering In-Reply-To: <20110512074850.GA9937@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> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 29956 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jmorris@namei.org Precedence: bulk X-list: linux-mips On Thu, 12 May 2011, Ingo Molnar wrote: > > 2) Why should this concept not be made available wider, to allow the > restriction of not just system calls but other security relevant components > of the kernel as well? Because the aim of this is to reduce the attack surface of the syscall interface. LSM is the correct level of abstraction for general security mediation, because it allows you to take into account all relevant security information in a race-free context. > This too, if you approach the problem via the events code, will be a natural > end result, while if you approach it from the seccomp prctl angle it will be > a limited hack only. I'd say it's a well-defined and readily understandable feature. - James -- James Morris 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 05FC01007D1 for ; Thu, 12 May 2011 21:49:19 +1000 (EST) Date: Thu, 12 May 2011 21:44:15 +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: <20110512074850.GA9937@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> 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 , linux-arm-kernel@lists.infradead.org, kees.cook@canonical.com, "Serge E. Hallyn" , Peter Zijlstra , microblaze-uclinux@itee.uq.edu.au, Steven Rostedt , Martin Schwidefsky , Thomas Gleixner , Roland McGrath , Michal Marek , Michal Simek , Will Drewry , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Ralf Baechle , Paul Mundt , Tejun Heo , 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 Thu, 12 May 2011, Ingo Molnar wrote: > > 2) Why should this concept not be made available wider, to allow the > restriction of not just system calls but other security relevant components > of the kernel as well? Because the aim of this is to reduce the attack surface of the syscall interface. LSM is the correct level of abstraction for general security mediation, because it allows you to take into account all relevant security information in a race-free context. > This too, if you approach the problem via the events code, will be a natural > end result, while if you approach it from the seccomp prctl angle it will be > a limited hack only. I'd say it's a well-defined and readily understandable feature. - James -- James Morris From mboxrd@z Thu Jan 1 00:00:00 1970 From: jmorris@namei.org (James Morris) Date: Thu, 12 May 2011 21:44:15 +1000 (EST) Subject: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering In-Reply-To: <20110512074850.GA9937@elte.hu> References: <1304017638.18763.205.camel@gandalf.stny.rr.com> <1305169376-2363-1-git-send-email-wad@chromium.org> <20110512074850.GA9937@elte.hu> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, 12 May 2011, Ingo Molnar wrote: > > 2) Why should this concept not be made available wider, to allow the > restriction of not just system calls but other security relevant components > of the kernel as well? Because the aim of this is to reduce the attack surface of the syscall interface. LSM is the correct level of abstraction for general security mediation, because it allows you to take into account all relevant security information in a race-free context. > This too, if you approach the problem via the events code, will be a natural > end result, while if you approach it from the seccomp prctl angle it will be > a limited hack only. I'd say it's a well-defined and readily understandable feature. - James -- James Morris