lkml.org 
[lkml]   [2006]   [Apr]   [19]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC][PATCH 4/11] security: AppArmor - Core access controls
    FromStephen Smalley <>
    DateWed, 19 Apr 2006 15:50:43 -0400
    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 majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    
    
    \
     
     \ /
      Last update: 2006-04-19 21:49    [from the cache]
    ©2003-2008