From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 May 2011 17:30:50 +0200 (CEST) Received: from mx0.aculab.com ([213.249.233.131]:54879 "HELO mx0.aculab.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with SMTP id S1491851Ab1EMPao convert rfc822-to-8bit (ORCPT ); Fri, 13 May 2011 17:30:44 +0200 Received: (qmail 27983 invoked from network); 13 May 2011 15:30:30 -0000 Received: from localhost (127.0.0.1) by mx0.aculab.com with SMTP; 13 May 2011 15:30:30 -0000 Received: from mx0.aculab.com ([127.0.0.1]) by localhost (mx0.aculab.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 27321-03 for ; Fri, 13 May 2011 16:30:30 +0100 (BST) Received: (qmail 27800 invoked by uid 599); 13 May 2011 15:30:28 -0000 Received: from unknown (HELO saturn3.Aculab.com) (10.202.163.5) by mx0.aculab.com (qpsmtpd/0.28) with ESMTP; Fri, 13 May 2011 16:30:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: RE: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system callfiltering Date: Fri, 13 May 2011 16:29:27 +0100 Message-ID: In-Reply-To: <1305299880.2076.31.camel@localhost.localdomain> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system callfiltering Thread-Index: AcwRgP+uf4p6VPi/TNeaJPKux9Io6gAAKobQ From: "David Laight" To: "Eric Paris" , "Ingo Molnar" Cc: , , "Peter Zijlstra" , "Frederic Weisbecker" , "Heiko Carstens" , "Oleg Nesterov" , "David Howells" , "Paul Mackerras" , "H. PeterAnvin" , , "Jiri Slaby" , , "Russell King" , , "James Morris" , "Linus Torvalds" , "Ingo Molnar" , , "Serge E. Hallyn" , "Steven Rostedt" , "Tejun Heo" , "Thomas Gleixner" , , "Michal Marek" , "Michal Simek" , "Will Drewry" , , , "Ralf Baechle" , "Paul Mundt" , "Martin Schwidefsky" , , "Andrew Morton" , , "David S. Miller" X-Virus-Scanned: by iCritical at mx0.aculab.com 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: 29999 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: David.Laight@ACULAB.COM Precedence: bulk X-list: linux-mips > ... 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 :) For a bad example of trying to allow alternate security models look at NetBSD's kauth code :-) NetBSD also had issues where some 'system call trace' code was being used to (try to) apply security - unfortunately it worked by looking at the user-space buffers on system call entry - and a multithreaded program can easily arrange to update them after the initial check! For trace/event type activities this wouldn't really matter, for security policy it does. (I've not looked directly at these event points in linux) David From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0.aculab.com ([213.249.233.131]:54879 "HELO mx0.aculab.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with SMTP id S1491851Ab1EMPao convert rfc822-to-8bit (ORCPT ); Fri, 13 May 2011 17:30:44 +0200 Received: from mx0.aculab.com ([127.0.0.1]) by localhost (mx0.aculab.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 27321-03 for ; Fri, 13 May 2011 16:30:30 +0100 (BST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: RE: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system callfiltering Date: Fri, 13 May 2011 16:29:27 +0100 Message-ID: In-Reply-To: <1305299880.2076.31.camel@localhost.localdomain> From: "David Laight" Return-Path: Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org To: Eric Paris , Ingo Molnar Cc: linux-mips@linux-mips.org, linux-sh@vger.kernel.org, Peter Zijlstra , Frederic Weisbecker , Heiko Carstens , Oleg Nesterov , David Howells , Paul Mackerras , "H. PeterAnvin" , 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" Message-ID: <20110513152927.Nvd1Y6wSSylNBhmh-7zntWpEDVE7tR0so2wOsS1lHdQ@z> > ... 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 :) For a bad example of trying to allow alternate security models look at NetBSD's kauth code :-) NetBSD also had issues where some 'system call trace' code was being used to (try to) apply security - unfortunately it worked by looking at the user-space buffers on system call entry - and a multithreaded program can easily arrange to update them after the initial check! For trace/event type activities this wouldn't really matter, for security policy it does. (I've not looked directly at these event points in linux) David From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0.aculab.com (mx0.aculab.com [213.249.233.131]) by ozlabs.org (Postfix) with SMTP id 0B944B6EFF for ; Sat, 14 May 2011 01:30:38 +1000 (EST) Received: from mx0.aculab.com ([127.0.0.1]) by localhost (mx0.aculab.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 25566-10 for ; Fri, 13 May 2011 16:30:31 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system callfiltering Date: Fri, 13 May 2011 16:29:27 +0100 Message-ID: In-Reply-To: <1305299880.2076.31.camel@localhost.localdomain> From: "David Laight" To: "Eric Paris" , "Ingo Molnar" Cc: linux-mips@linux-mips.org, linux-sh@vger.kernel.org, Peter Zijlstra , Frederic Weisbecker , Heiko Carstens , linux-kernel@vger.kernel.org, David Howells , Paul Mackerras , "H. PeterAnvin" , sparclinux@vger.kernel.org, Jiri Slaby , linux-s390@vger.kernel.org, Russell King , x86@kernel.org, James Morris , Ingo Molnar , kees.cook@canonical.com, "Serge E. Hallyn" , Steven Rostedt , Martin Schwidefsky , Thomas Gleixner , agl@chromium.org, linux-arm-kernel@lists.infradead.org, Michal Marek , Michal Simek , Will Drewry , linuxppc-dev@lists.ozlabs.org, Oleg Nesterov , Ralf Baechle , Paul Mundt , Tejun Heo , linux390@de.ibm.com, Andrew Morton , Linus Torvalds , "David S. Miller" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , > ... 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 :) For a bad example of trying to allow alternate security models look at NetBSD's kauth code :-) NetBSD also had issues where some 'system call trace' code was being used to (try to) apply security - unfortunately it worked by looking at the user-space buffers on system call entry - and a multithreaded program can easily arrange to update them after the initial check! For trace/event type activities this wouldn't really matter, for security policy it does. (I've not looked directly at these event points in linux) David From mboxrd@z Thu Jan 1 00:00:00 1970 From: David.Laight@ACULAB.COM (David Laight) Date: Fri, 13 May 2011 16:29:27 +0100 Subject: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system callfiltering In-Reply-To: <1305299880.2076.31.camel@localhost.localdomain> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org > ... 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 :) For a bad example of trying to allow alternate security models look at NetBSD's kauth code :-) NetBSD also had issues where some 'system call trace' code was being used to (try to) apply security - unfortunately it worked by looking at the user-space buffers on system call entry - and a multithreaded program can easily arrange to update them after the initial check! For trace/event type activities this wouldn't really matter, for security policy it does. (I've not looked directly at these event points in linux) David