From mboxrd@z Thu Jan 1 00:00:00 1970 From: Casey Schaufler Subject: Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook Date: Fri, 25 May 2007 13:27:54 -0700 (PDT) Message-ID: <312681.33492.qm@web36609.mail.mud.yahoo.com> References: <200705252200.21765.agruen@suse.de> Reply-To: casey@schaufler-ca.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Cc: Jeremy Maitin-Shepard , James Morris , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org To: Andreas Gruenbacher Return-path: In-Reply-To: <200705252200.21765.agruen@suse.de> Sender: linux-security-module-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org --- Andreas Gruenbacher wrote: > On Friday 25 May 2007 19:43, Casey Schaufler wrote: > > [...] but the AppArmor code could certainly check for that in exec by > > enforcing the argv[0] convention. It would be perfectly reasonable for a > > system that is so dependent on pathnames to require that. > > Hmm ... that's a strange idea. Yeah, I get that a lot. > AppArmor cannot assume anything about argv[0], > > and it would be a really bad idea to change the well-established semantics of > > argv[0]. > > There is no actual need for looking at argv[0], though: AppArmor decides > based > on the actual pathname of the executable... Right. My point was that if you wanted to use the gzip/gunzip example of a file with two names being treated differently based on the name accessed as an argument for AppArmor you could. If you don't want to, that's ok too. Jeremy raised a reasonable objection, and AppArmor could address it if y'all chose to do so. I seriously doubt that enforcing the argv[0] convention would break much, and I also expect that if it did there's a Consultant's Retirement to be made fixing the security hole it points out. Casey Schaufler casey@schaufler-ca.com