text: On Wed, Apr 19, 2006 at 08:10:30PM +0200, Arjan van de Ven wrote:> On Wed, 2006-04-19 at 10:49 -0700, Tony Jones wrote:> > +/**> > + * _aa_perm_dentry> > + * @active: profile to check against> > + * @dentry: requested dentry> > + * @mask: mask of requested operations> > + * @pname: pointer to hold matched pathname (if any)> > + *> > + * Helper function. Obtain pathname for specified dentry. > > which namespace will this be in?We perform validation relative to the current tasks namespace> > Verify if profile> > + * authorizes mask operations on pathname (due to lack of vfsmnt it is sadly> > + * necessary to search mountpoints in namespace -- when nameidata is passed> > + * more fully, this code can go away). If more than one mountpoint matches> > + * but none satisfy the profile, only the first pathname (mountpoint) is> > + * returned for subsequent logging.> > that sounds too bad ;) > If I manage to mount /etc/passwd as /tmp/passwd, you'll only find the> later and your entire security system seems to be down the drain.Well first off, as addressed elsewhere, a confined task cannot mount.Also, if you do bind mount as above, we will find both but we only reportthe first. The path reported in this event will be used to generate policy.Clearly if the ordering of which entry is found first varies, then for asubsequent iteration, the policy may not be sufficient to grant the task access and it will likely fail. This is important, a failure to specify a path in a profile results in a failure of access not a allowal of access. Solution, include all paths in the profile confining the task.I do grant that a situation of very temporal mounts can make the generation of a sane profile difficult. I've not used namespaces in such a manner soI've not seen exactly how bad it is. One of my hopes from this thread wasthat people would post real life in the trenches with namespaces examples,both to aid us and maybe to illustrate where our approach is broken. Likewise if you generate policy in an environment with a large number of mounts which will not esist when the task runs under policy enforcement, you could run into issues.> > + filename = aa_get_name(filp->f_dentry, filp->f_vfsmnt);> > what if filp->f_dentry is NULL ?> like when the file got unlinked under you?I believe there is a misunderstanding about the value of a unhashed dentry when a file is unlinked from under a task. I responded to a more detailed version of the same question posted by Valdis Kletniek. Thanks for the post.Tony-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.kernel.orgMore majordomo info at read the FAQ at