Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756718AbXJHSxT (ORCPT ); Mon, 8 Oct 2007 14:53:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755264AbXJHSxK (ORCPT ); Mon, 8 Oct 2007 14:53:10 -0400 Received: from e3.ny.us.ibm.com ([32.97.182.143]:46547 "EHLO e3.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755236AbXJHSxI (ORCPT ); Mon, 8 Oct 2007 14:53:08 -0400 Date: Mon, 8 Oct 2007 13:53:04 -0500 From: "Serge E. Hallyn" To: "Eric W. Biederman" Cc: casey@schaufler-ca.com, Stephen Smalley , Kyle Moffett , Linus Torvalds , Bill Davidsen , James Morris , Andrew Morton , linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, "Serge E. Hallyn" Subject: Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel Message-ID: <20071008185304.GA17671@sergelap.austin.ibm.com> References: <54877.16343.qm@web36603.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2818 Lines: 57 Quoting Eric W. Biederman (ebiederm@xmission.com): > Casey Schaufler writes: > > > --- "Eric W. Biederman" wrote: > > > > > >> Likely. Until we have a generalized LSM interface with 1000 config > >> options like netfilter I don't expect we will have grounds to talk > >> or agree to a common user space interface. Although I could be > >> wrong. > > > > Gulp. I know that many of you are granularity advocates, but I > > have to say that security derived by tweeking 1000 knobs so that > > they are all just right seems a little far fetched to me. I see > > it as poopooing the 3rd and most important part of the reference > > monitor concept, "small enough to analyze". Sure, you can analyse > > the 1000 individual checks, but you'll never be able to describe > > the system behavior as a whole. > > Agreed. I wasn't thinking 1000 individual checks but 1000 different > capabilities, could be either checks or actions, basically fundamental > different capabilities. Things like CIPSO, or the ability to store a > security label on a file. I would not expect most security policies > to use most of them. Neither do I expect Orange book security to > necessarily be what people want to achieve with the LSM. But I > haven't looked at it enough detail to know how things should be > factored, in this case I was simply extrapolating from the iptables > experience where we do have a very large number of options. > > The real point being is that I would be surprised if we could come > to an agreement of a common user space API when we can't agree on how > to compile all of the security modules into the kernel and have them > play nice with each other. > > Assuming we can achieve security modules playing nice with each other > using a mechanism similar to iptables, then what needs to be evaluated > is the specific table configuration we are using on the system, not > the full general set of possibilities. Further I expect that for the > truly security paranoid we want the option to disable further table > changes after the tables have been configured. > > On another side personally I don't see where the idea comes from that > you can describe system behavior as a whole without analyzing the > entire kernel. Has there been work on a sparse like tool that I'm > not aware of to ensure the we always perform the appropriate security > checks on the user/kernel interface boundary? Yup, see the top of http://www.research.ibm.com/vali/ Pretty cool work that really should be continued. -serge - 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/