Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755125Ab1EZRCr (ORCPT ); Thu, 26 May 2011 13:02:47 -0400 Received: from mail-fx0-f46.google.com ([209.85.161.46]:44251 "EHLO mail-fx0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751638Ab1EZRCq convert rfc822-to-8bit (ORCPT ); Thu, 26 May 2011 13:02:46 -0400 MIME-Version: 1.0 In-Reply-To: References: <1305807728.11267.25.camel@gandalf.stny.rr.com> <1306254027.18455.47.camel@twins> <20110524195435.GC27634@elte.hu> <20110525150153.GE29179@elte.hu> <20110525180100.GY19633@outflux.net> <20110525191152.GC19633@outflux.net> Date: Thu, 26 May 2011 12:02:45 -0500 Message-ID: Subject: Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering From: Will Drewry To: Linus Torvalds Cc: Colin Walters , Kees Cook , Thomas Gleixner , Ingo Molnar , Peter Zijlstra , Steven Rostedt , linux-kernel@vger.kernel.org, James Morris Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2030 Lines: 53 On Thu, May 26, 2011 at 11:46 AM, Linus Torvalds wrote: > On Thu, May 26, 2011 at 9:33 AM, Will Drewry wrote: >> >> FWIW, none of the patches deal with privilege escalation via setuid >> files or file capabilities. > > That is NOT AT ALL what I'm talking about. > > I'm talking about the "setuid()" system call (and all its cousins: > setgit/setreuid etc). And the whole thread has been about filtering > system calls, no? > > Do a google code search for setuid. > > In good code, it will look something like > > ?uid = getuid(); > > ?if (setuid(uid)) { > ? ?fprintf(stderr, "Unable to drop provileges\n"); > ? ?exit(1); > ?} > > but I guarantee you that there are cases where people just blindly > drop privileges. google code search found me at least the "heirloom" > source code doing exactly that. > > And if you filter system calls, it's entirely possible that you can > attack suid executables through such a vector. Your "limit system > calls for security" security suddenly turned into "avoid the system > call that made things secure"! > > See what I'm saying? Absolutely - that was what I meant :/ The patches do not currently check creds at creation or again at use, which would lead to unprivileged filters being used in a privileged context. Right now, though, if setuid() is not allowed by the seccomp-filter, the process will be immediately killed with do_exit(SIGKILL) on call -- thus avoiding a silent failure. I mentioned file capabilities because they can have setuid-like side effects, too. As long as system call rejection results in a process death, I *think* it helps with some of this complexity, but I haven't fully vetted the patches for these scenarios to be 100% confident. Sorry I wasn't clear! will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/