From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752755AbXE0JF1 (ORCPT ); Sun, 27 May 2007 05:05:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752463AbXE0JFH (ORCPT ); Sun, 27 May 2007 05:05:07 -0400 Received: from fep07.mfe.bur.connect.com.au ([203.63.86.27]:47829 "EHLO fep07.mfe.bur.connect.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751798AbXE0JFF (ORCPT ); Sun, 27 May 2007 05:05:05 -0400 X-Greylist: delayed 1691 seconds by postgrey-1.27 at vger.kernel.org; Sun, 27 May 2007 05:05:04 EDT Message-ID: <46594282.8010307@iinet.net.au> Date: Sun, 27 May 2007 16:34:10 +0800 From: Cliffe User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Kyle Moffett CC: casey@schaufler-ca.com, Andreas Gruenbacher , James Morris , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook References: <309300.41401.qm@web36615.mail.mud.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org >> On the other hand, if you actually want to protect the _data_, then tagging the _name_ is flawed; tag the *DATA* instead. Would it make sense to label the data (resource) with a list of paths (names) that can be used to access it? Therefore the data would be protected against being accessed via alternative arbitrary names. This may be a simple label to maintain and (possibly to) enforce, allowing path based confinement to protect a resource. This may allow for the benefits of pathname based confinement while avoiding some of its problems. Obviously this would not protect against a pathname pointing to arbitrary data… Just a thought. Z. Cliffe Schreuders. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cliffe Subject: Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook Date: Sun, 27 May 2007 16:34:10 +0800 Message-ID: <46594282.8010307@iinet.net.au> References: <309300.41401.qm@web36615.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: casey@schaufler-ca.com, Andreas Gruenbacher , James Morris , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org To: Kyle Moffett Return-path: In-Reply-To: Sender: linux-security-module-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org >> On the other hand, if you actually want to protect the _data_, then= =20 tagging the _name_ is flawed; tag the *DATA* instead. Would it make sense to label the data (resource) with a list of paths=20 (names) that can be used to access it? Therefore the data would be protected against being accessed via=20 alternative arbitrary names. This may be a simple label to maintain and= =20 (possibly to) enforce, allowing path based confinement to protect a=20 resource. This may allow for the benefits of pathname based confinement= =20 while avoiding some of its problems. Obviously this would not protect against a pathname pointing to=20 arbitrary data=85 Just a thought. Z. Cliffe Schreuders. - To unsubscribe from this list: send the line "unsubscribe linux-securit= y-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html