Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758335Ab1EZTtv (ORCPT ); Thu, 26 May 2011 15:49:51 -0400 Received: from mail.lang.hm ([64.81.33.126]:57121 "EHLO bifrost.lang.hm" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751980Ab1EZTtu (ORCPT ); Thu, 26 May 2011 15:49:50 -0400 Date: Thu, 26 May 2011 12:49:15 -0700 (PDT) From: david@lang.hm X-X-Sender: dlang@asgard.lang.hm To: Ingo Molnar cc: Linus Torvalds , Will Drewry , Colin Walters , Kees Cook , Thomas Gleixner , Peter Zijlstra , Steven Rostedt , linux-kernel@vger.kernel.org, James Morris Subject: Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering In-Reply-To: <20110526194621.GB6363@elte.hu> Message-ID: References: <20110526184723.GA3177@elte.hu> <20110526194621.GB6363@elte.hu> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2519 Lines: 57 On Thu, 26 May 2011, Ingo Molnar wrote: > * david@lang.hm wrote: > >> On Thu, 26 May 2011, Ingo Molnar wrote: >> >>> * Linus Torvalds wrote: >>> >>>> It also gets rid of all configuration - one of the things that >>>> makes most security frameworks (look at selinux, but also just >>>> ACL's etc) such a crazy rats nest is the whole "set up for other >>>> processes". If it's designed very much to be about just the "self" >>>> process (after initialization etc), then I think that avoids pretty >>>> much all the serious issues. >>> >>> That's how the event filters work currently: even when inherited they >>> get removed when exec-ing a setuid task, so they cannot leak into >>> privileged context and cannot modify execution there. >>> >>> Inheritance works when requested, covering only same-credential child >>> tasks, not privileged successors. >> >> this is a very reasonable default, but there should be some way of >> saying that you want the restrictions to carry over to the suid >> task (I really know what I'm doing switch) > > Unless you mean that root should be able to do it it's a security > hole both for events and for filters: > > - for example we dont want really finegrained events to be used to > BTS hw-trace sshd and thus enable it to discover cryptographic > properties of the private key sshd is using. > > - we do not want to *modify* the execution flow of a setuid program, > that can lead to exploits: by pushing the privileged codepath into > a condition that can never occur on a normal system - and thus can > push it into doing something it was not intended to do. > > data damage could be done as well: for example if the privileged > code is logging into a system file then modifying execution can > damage the log file. > > So it's not a good idea in general to allow unprivileged code to > modify the execution of privileged code. In fact it's not a good idea > to allow it to simply *observe* privileged code. It must remain a > black box with very few information leaking outwards. I was thinking of the use case of the real sysadmin (i.e. root) wanting to be able to constrain things. I can see why you would not want to allow normal users to do this. David Lang -- 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/