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 B1BF2B6F97 for ; Thu, 26 May 2011 18:36:10 +1000 (EST) Date: Thu, 26 May 2011 10:35:13 +0200 From: Ingo Molnar To: Pavel Machek Subject: Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering Message-ID: <20110526083513.GC26775@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> <20110526062752.GA14622@localhost.ucw.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20110526062752.GA14622@localhost.ucw.cz> 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 , Ralf Baechle , "H. Peter Anvin" , 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" , Peter Zijlstra , 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 , Eric Paris , 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: , * Pavel Machek wrote: > On Mon 2011-05-16 10:36:05, James Morris wrote: > > On Fri, 13 May 2011, Ingo Molnar wrote: > > 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. > > Well, you can do the same with subterfugue, even without kernel > changes. But that's ptrace -- slow. (And it already shows that > syscall based filters are extremely tricky to configure). Yes, if you use syscall based filters to implement access to underlying objects where the access methods do not capture essential lifetime events properly (such as files) they you'll quickly run into trouble achieving a secure solution. But you can robustly use syscall filters to control the underlying primary *resource*: various pieces of kernel code with *negative* utility to the current app - which have no use to the app but pose risks in terms of potential exploits in them. But you can use event filters to implement arbitrary security policies robustly. For example file objects: if you generate the right events for a class of objects then you can control access to them very robustly. It's not a surprise that this is what SELinux does primarily: it has lifetime event hooks at the inode object (and socket, packet, etc.) level and captures those access attempts and validates them against the permissions of that object, in light of the accessing task's credentials. Exactly that can be done with Will's patch as well, if its potential scope of event-checking points is not stupidly limited to the syscall boundary alone ... Thanks, Ingo