From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 May 2011 15:11:38 +0200 (CEST) Received: from mx2.mail.elte.hu ([157.181.151.9]:59884 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S1491069Ab1EQNLd (ORCPT ); Tue, 17 May 2011 15:11:33 +0200 Received: from elvis.elte.hu ([157.181.1.14]) by mx2.mail.elte.hu with esmtp (Exim) id 1QMK3B-0005xB-Lf from ; Tue, 17 May 2011 15:11:07 +0200 Received: by elvis.elte.hu (Postfix, from userid 1004) id F35413E2533; Tue, 17 May 2011 15:10:58 +0200 (CEST) Date: Tue, 17 May 2011 15:10:58 +0200 From: Ingo Molnar To: James Morris 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 , Jiri Slaby , 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, 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 Message-ID: <20110517131058.GE21441@elte.hu> 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> <20110516150837.GA513@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-08-17) Received-SPF: neutral (mx2.mail.elte.hu: 157.181.1.14 is neither permitted nor denied by domain of elte.hu) client-ip=157.181.1.14; envelope-from=mingo@elte.hu; helo=elvis.elte.hu; X-ELTE-SpamScore: -2.0 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-2.0 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.3.1 -2.0 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 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: 30064 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: mingo@elte.hu Precedence: bulk X-list: linux-mips * James Morris wrote: > On Mon, 16 May 2011, Ingo Molnar wrote: > > > > Not really. > > > > > > Firstly, what is the security goal of these restrictions? [...] > > > > To do what i described above? Namely: > > > > " Sandboxed code should only be allowed to open files in /home/sandbox/, /lib/ > > and /usr/lib/ " > > These are access rules, they don't really describe a high-level security > goal. [...] Restrictng sandboxed code to only open files within a given VFS namespace boundary sure sounds like a high-level security goal to me. If implemented and set up correctly then it restricts sandboxed code to only be able to open files reachable via that VFS sub-namespace. That is a rather meaningful high-level concept. What higher level concept do you want to argue? > [...] How do you know it's ok to open everything in these directories? How do you know it's ok to open /etc/hosts? The sysadmin has configured the system that way. How do you know that it's ok for sandboxed code to open files in /home/sandbox/? The sandbox developer has configured the system that way. I'm not sure i get your point. Thanks, Ingo 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 22360B6EEC for ; Tue, 17 May 2011 23:11:34 +1000 (EST) Date: Tue, 17 May 2011 15:10:58 +0200 From: Ingo Molnar To: James Morris Subject: Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering Message-ID: <20110517131058.GE21441@elte.hu> 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> <20110516150837.GA513@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 , 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: , * James Morris wrote: > On Mon, 16 May 2011, Ingo Molnar wrote: > > > > Not really. > > > > > > Firstly, what is the security goal of these restrictions? [...] > > > > To do what i described above? Namely: > > > > " Sandboxed code should only be allowed to open files in /home/sandbox/, /lib/ > > and /usr/lib/ " > > These are access rules, they don't really describe a high-level security > goal. [...] Restrictng sandboxed code to only open files within a given VFS namespace boundary sure sounds like a high-level security goal to me. If implemented and set up correctly then it restricts sandboxed code to only be able to open files reachable via that VFS sub-namespace. That is a rather meaningful high-level concept. What higher level concept do you want to argue? > [...] How do you know it's ok to open everything in these directories? How do you know it's ok to open /etc/hosts? The sysadmin has configured the system that way. How do you know that it's ok for sandboxed code to open files in /home/sandbox/? The sandbox developer has configured the system that way. I'm not sure i get your point. Thanks, Ingo From mboxrd@z Thu Jan 1 00:00:00 1970 From: mingo@elte.hu (Ingo Molnar) Date: Tue, 17 May 2011 15:10:58 +0200 Subject: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering In-Reply-To: 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> <20110516150837.GA513@elte.hu> Message-ID: <20110517131058.GE21441@elte.hu> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org * James Morris wrote: > On Mon, 16 May 2011, Ingo Molnar wrote: > > > > Not really. > > > > > > Firstly, what is the security goal of these restrictions? [...] > > > > To do what i described above? Namely: > > > > " Sandboxed code should only be allowed to open files in /home/sandbox/, /lib/ > > and /usr/lib/ " > > These are access rules, they don't really describe a high-level security > goal. [...] Restrictng sandboxed code to only open files within a given VFS namespace boundary sure sounds like a high-level security goal to me. If implemented and set up correctly then it restricts sandboxed code to only be able to open files reachable via that VFS sub-namespace. That is a rather meaningful high-level concept. What higher level concept do you want to argue? > [...] How do you know it's ok to open everything in these directories? How do you know it's ok to open /etc/hosts? The sysadmin has configured the system that way. How do you know that it's ok for sandboxed code to open files in /home/sandbox/? The sandbox developer has configured the system that way. I'm not sure i get your point. Thanks, Ingo