Hello.
Al Viro wrote:
> On Fri, Jan 25, 2008 at 07:20:56PM +0900, Kentaro Takeda wrote:
> > In the LSM ml, we are discussing about
> > "how to know requested pathnames within LSM modules".
> >
> > Currently, VFS helper functions don't pass "struct vfsmount" parameter.
> > Therefore, we cannot calculate requested pathnames within LSM modules
> > because LSM hooks can't know "struct vfsmount" parameter that corresponds with
> > "struct dentry" passed to VFS helper functions.
> >
> > AppArmor is proposing a patch that appends "struct vfsmount" parameters to
> > VFS helper functions so that LSM modules (SELinux, AppArmor, TOMOYO) can
> > calculate requested pathnames.
> >
> > The changes in include/linux/fs.h are shown below.
> > What do you think about these changes?
>
> That they are bloody *wrong*. You have not addressed any of the objections
> that had been posted too many times to repeat. Damn it, you've not even
> bothered to deal with the specific obvious stupidity with vfs_rename() -
> just reposted the dreck and devil take all feedback. Wonderful...
>
Thank you for your opinion.
Which one is closer to your opinion?
(1) I can never accept LSM modules from accessing
pathname of requested "struct dentry".
(2) I accept LSM modules from accessing
pathname of requested "struct dentry",
but the approach is too ugly to accept.
If your opinion is (1), I have no idea to propose.
If your opinion is (2), there are several approaches.
(a) Add "struct vfsmount" to VFS related functions.
This is what AppArmor proposes and TOMOYO 2.x can accept.
http://lkml.org/lkml/2007/10/26/87
(b) Make "struct vfsmount" retrievable via "struct task_struct".
This is what TOMOYO 2.x proposes. "struct task_struct" holds
pointer to "struct vfsmount" which is pushed on the stack.
http://lkml.org/lkml/2007/11/16/185
Advantage is that we don't need to add "struct vfsmount" parameter to VFS functions.
Disadvantage is that we have to add lots of VFS wrapper functions.
(c) Add new hooks.
This is what TOMOYO 1.x is doing.
Introduce a function which performs DAC checks (e.g. pre_vfs_link() at
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/fs/namei.c?v=linux-2.6.24-tomoyo-1.5.3#L2421 )
and a function which performs MAC checks (e.g. CheckDoubleWritePermission()).
Advantage is that we don't need to add "struct vfsmount" parameter to VFS functions.
Disadvantage is that we have to add lots of hooks and DAC permission checks are performed twice.
(d) Calculate pathname while doing name resolution (i.e. __link_path_walk() at fs/namei.c)
and keep the result in "struct dentry" (or may be "struct file").
This approach would yield the most accurate result because
it doesn't access "struct dentry"->d_parent element.
But I think it is a too large performance hit because it may entail
memory allocation whenever one directory component is resolved and
it is a memory consuming thing because pathnames stored in most "struct dentry" instances
are not used by MAC checks.
Saving pathname of name resolution time might help handling lazy unmounting problem.
But is it desirable to reuse pathname of name resolution time even if the location of
a file changed after the name resolution has completed?
(e) Calculate pathname inside LSM modules.
This is not usable because this causes "namespace_sem" deadlock.
http://lkml.org/lkml/2007/11/5/388
... and more possible approaches ?
Regards.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
