From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750831AbWDRXQ7 (ORCPT ); Tue, 18 Apr 2006 19:16:59 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750799AbWDRXQ7 (ORCPT ); Tue, 18 Apr 2006 19:16:59 -0400 Received: from web36613.mail.mud.yahoo.com ([209.191.85.30]:19072 "HELO web36613.mail.mud.yahoo.com") by vger.kernel.org with SMTP id S1750824AbWDRXQ6 (ORCPT ); Tue, 18 Apr 2006 19:16:58 -0400 Message-ID: <20060418231657.68869.qmail@web36613.mail.mud.yahoo.com> X-RocketYMMF: rancidfat Date: Tue, 18 Apr 2006 16:16:57 -0700 (PDT) From: Casey Schaufler Reply-To: casey@schaufler-ca.com Subject: Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks To: James Morris Cc: linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, fireflier-devel@lists.sourceforge.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org --- James Morris wrote: > No. The inode design is simply correct. If this were true audit records would not be required to contain path names. Names are important. To meet EAL requirements path names are demonstrably insufficient, but so too are inode numbers. Unless you want to argue that Linux is unevaluateable (a pretty tough position to defend) because it requires both in an audit record you cannot claim either is definitive. Casey Schaufler casey@schaufler-ca.com