From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965015AbWD0R6S (ORCPT ); Thu, 27 Apr 2006 13:58:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S965018AbWD0R6S (ORCPT ); Thu, 27 Apr 2006 13:58:18 -0400 Received: from uproxy.gmail.com ([66.249.92.171]:13401 "EHLO uproxy.gmail.com") by vger.kernel.org with ESMTP id S965015AbWD0R6Q convert rfc822-to-8bit (ORCPT ); Thu, 27 Apr 2006 13:58:16 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KJW02c81AoFEPukybPaI/KhaFP3F5QERLYjyJn0RAJ1tIzHdlSKE2bJHfLCY3iZrx3N6oO/EHDWnvqSbRfKyPd8VPgY0OHp1kQOjh/x3rb/OqbbVu5DWv7mPVV0KkrZu+IHYj5hZV6/Ek6Qd+iuVhRQyrKcuajyZ0F7wLVKnunM= Message-ID: Date: Thu, 27 Apr 2006 10:58:15 -0700 From: "Ken Brush" To: "Stephen Smalley" Subject: Re: Some Concrete AppArmor Questions - was Re: [RFC][PATCH 0/11] security: AppArmor - Overview Cc: "Neil Brown" , "Chris Wright" , "James Morris" , "Arjan van de Ven" , "Andi Kleen" , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org In-Reply-To: <1146159833.5238.95.camel@moss-spartans.epoch.ncsc.mil> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Disposition: inline References: <20060419174905.29149.67649.sendpatchset@ermintrude.int.wirex.com> <20060421173008.GB3061@sorel.sous-sol.org> <1145642853.21749.232.camel@moss-spartans.epoch.ncsc.mil> <17484.20906.122444.964025@cse.unsw.edu.au> <1145911526.14804.71.camel@moss-spartans.epoch.ncsc.mil> <17485.55676.177514.848509@cse.unsw.edu.au> <1145984831.21399.74.camel@moss-spartans.epoch.ncsc.mil> <17487.61698.879132.891619@cse.unsw.edu.au> <1146159833.5238.95.camel@moss-spartans.epoch.ncsc.mil> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On 4/27/06, Stephen Smalley wrote: > On Wed, 2006-04-26 at 16:06 -0700, Ken Brush wrote: > > On 4/26/06, Neil Brown wrote: > > > > > > I feel we have reached the stage where the questions/comments being > > > made are actually directly relevant to AppArmor. I'm afraid I cannot > > > proceed any further now because I am not a security expert. > > > > > > I would like to summarise what I think are the key points that you > > > have raised, and hope that someone who has a deeper understanding of > > > these things might answer them, or point to answers. > > > > > > 1/ Does AppArmor's primary mechanism of confining an application to a > > > superset of it's expected behaviour actually achieve its secondary > > > gaol of protecting data? > > > > > > Possibly it would be better to ask "When does ..." as I think it is > > > easy to imagine application/profile pairs that clearly cannot allow > > > harm, and application/profile pairs that clearly could allow harm. > > > > Depends on the data. A properly constrained Apache webserver would be > > prevented from accessing data it shouldn't. > > No, it wouldn't. The question itself is flawed - it presumes that AA > does confine the application to its expected behavior. I can confine a process to my idea of it's expected behavior. > But with > incomplete mediation and ambiguous identifiers, there is no such > guarantee. No profile will meet the "clearly cannot allow harm" > definition, because not all operations are controlled by it and of the > operations that are controlled, the actual objects are not clearly > identified, so harm is still possible. > I can guarantee that if my profile does not allow write access to /etc that apache's write to "/etc/new_file" will not be allowed. The argument that somehow someone would setup a soft link or something so that apache could write to /etc via indirection is not my primary concern. That is systematic of a more concerted attack and a very determined attacker. Or at the very least, a mistake on my part. And in that case, I cannot protect myself from myself. > > > 2/ What advantages does AppArmor provide over techniques involving > > > virtualisation or gaol mechanisms? Are these advantages worth > > > while? > > > > If you just wish to run every application in a chrooted jail. Would > > you still need a MAC solution? > > If your goal is purely isolation, then virtualization may fit your > needs. If you want to support controlled sharing of data while still > ensuring that certain confidentiality and integrity goals are met, then > you want a MAC mechanism. But AA really isn't a MAC mechanism, despite > what its documentation may say. I have no requirements like that. I just would prefer that when people try to exploit my internet services, that the programs are not allowed to do things that I would rather it not do. AA seems to fulfill that requirement. -Ken