Re: [RFC][PATCH 4/11] security: AppArmor - Core access controls

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2006-04-19 at 10:49 -0700, Tony Jones wrote:
> +/**
> + * aa_get_name - retrieve fully qualified path name
> + * @dentry: relative path element
> + * @mnt: where in tree
> + *
> + * Returns fully qualified path name on sucess, NULL on failure.
> + * aa_put_name must be used to free allocated buffer.
> + */
> +char *aa_get_name(struct dentry *dentry, struct vfsmount *mnt)
> +{
> +	char *page, *name = NULL;
> +
> +	page = (char *)__get_free_page(GFP_KERNEL);
> +	if (!page)
> +		goto out;
> +
> +	name = d_path_flags(dentry, mnt, page, PAGE_SIZE,
> +			DPATH_SYSROOT|DPATH_NODELETED);

So on every inode hook call, you end up allocating a temporary page,
calling d_path (taking global dcache_lock), and you do this possibly
multiple times per object (due to iterating over vfsmounts) and you may
need to do it for multiple objects on a single hook call (e.g.
link/rename).   Is that correct?

> +/**
> + * aa_perm_nameidata: interface to sd_perm accepting nameidata
> + * @active: profile to check against
> + * @nd: namespace data (for vfsmnt and dentry)
> + * @mask: access mode requested
> + */
> +int aa_perm_nameidata(struct aaprofile *active, struct nameidata *nd, int mask)
> +{
> +	int error = 0;
> +
> +	if (nd)
> +		error = aa_perm(active, nd->dentry, nd->mnt, mask);
> +
> +	return error;
> +}

So what about the !nd case.  For when permission(9) is called with a
NULL nameidata.  Unconditional success in that case seems a bit
worrisome.

I also vaguely recall a problem with trying to use the nameidata
(vfsmount, dentry) pair to d_path in SELinux for audit purposes back
when avc_audit was trying to audit paths before migrating to using the
audit system for that purpose.  Interacted badly with rpc_pipefs upon
rpc_lookup_parent, IIRC.  Might want to check whether you handle it
correctly.

-- 
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux