end of attach_pathlabel (was Re: Kernel Security Extensions USENIX BOF Summary)

Previous message: Timothy Fraser: "Re: Kernel Security Extensions USENIX BOF Summary"
In reply to: Stephen Smalley: "Re: Kernel Security Extensions USENIX BOF Summary"
Next in thread: Greg KH: "Re: end of attach_pathlabel (was Re: Kernel Security Extensions USENIX BOF Summary)"
Next in thread: Timothy Fraser: "Re: Kernel Security Extensions USENIX BOF Summary"
Reply: Greg KH: "Re: end of attach_pathlabel (was Re: Kernel Security Extensions USENIX BOF Summary)"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

hallynat_private

Stephen Smalley <sdsat_private> wrote:
> Let me also return to the original point that started this discussion.
> Some of the attach_pathlabel hook calls are redundant with the
> post_create/mkdir/... hook calls.  Can we at least eliminate those
> attach_pathlabel calls?  As I've said previously, our confidence
...
> Also, can we do some analysis of the other attach_pathlabel hook calls
> to see if they might be bypassable?  Again, this is my motivation
> for pushing them down to lower-level lookup hook calls, so that
> I can have greater confidence that every inode gets "attached".

Since the 2.4.6 (pre?)patch is not up, and i don't have access to
bitkeeper just now, I'd like to quickly outline a proposal for
getting rid of attach_pathlabel:

1. er, remove all calls to attach_pathlabel.

2. add a hook in fs/namei.c:real_lookup, right before the
first 'return result'.  
		security_ops->inode_ops->post_lookup(struct inode *ino,
				struct qstr *name);

For my own purposes, I need the parent inode and the lookup name.  So
the first argument can be 'parent' or 'dir', and the second can be
'name' or 'dentry'.

And a few hooks in fs/super.c.  Maybe these could sync with the
existing add_vfsmnt hooks but since those are changing for 2.4.6,
I'll just list them explicitly.

3. do_loopback:  after graft_tree,
		security_ops->post_graft(struct vfsmount *mnt,
				struct nameidata mountpoint_nd);

4. do_add_mount: after graft_tree,
		security_ops->post_graft(struct vfsmount *mnt,
				struct nameidata mountpoint_nd);

5. mount_root: after add_vfsmnt,
		security_ops->post_mountroot(struct super_block *sb);

Comments?

-serge

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module