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