Re: [RFC] Add vfsmount to vfs helper functions.

2008-02-17 Thread Al Viro 
On Mon, Feb 18, 2008 at 09:03:51AM +0900, Tetsuo Handa wrote:
> Hello.
> 
> > No printable comments, except for that:
> > 
> > (e) why don't you guys move the Linus' Serious Mistake to _callers_ of
> > vfs_mknod() and its ilk?
> > 
> > Which obviously solves all problems with having vfsmount.
> 
> Excuse me. I didn't understand what "the Linus' Serious Mistake to
> _callers_ of vfs_mknod()" is. Could you give me some URLs or hints?

Linus' Serious Mistake: LSM.

Moving that junk to callers for vfs_mknod(): should be obvious; remove
the calls of security_whatever() from vfs_...() and add them in places
that call the functions in question.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Add vfsmount to vfs helper functions.

2008-02-17 Thread Tetsuo Handa 
Hello.

> No printable comments, except for that:
> 
> (e) why don't you guys move the Linus' Serious Mistake to _callers_ of
> vfs_mknod() and its ilk?
> 
> Which obviously solves all problems with having vfsmount.

Excuse me. I didn't understand what "the Linus' Serious Mistake to
_callers_ of vfs_mknod()" is. Could you give me some URLs or hints?

Regards.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Add vfsmount to vfs helper functions.

2008-02-17 Thread Al Viro 
On Sun, Feb 17, 2008 at 06:00:30PM +0900, Tetsuo Handa wrote:
> Hello.
> 
> This is "(c) Add new hooks." approach I proposed at
> http://www.mail-archive.com/linux-fsdevel@vger.kernel.org/msg11536.html .
> 
> Although this is an incomplete patch,
> I want to know whether you can tolerate this approach or not.
> 
> If you cannot tolerate this approach, may be we need to consider
> implementing "(d) Calculate pathname while doing name resolution" approach.
> 

No printable comments, except for that:

(e) why don't you guys move the Linus' Serious Mistake to _callers_ of
vfs_mknod() and its ilk?

Which obviously solves all problems with having vfsmount.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Add vfsmount to vfs helper functions.

2008-02-17 Thread Tetsuo Handa 
Hello.

This is "(c) Add new hooks." approach I proposed at
http://www.mail-archive.com/linux-fsdevel@vger.kernel.org/msg11536.html .

Although this is an incomplete patch,
I want to know whether you can tolerate this approach or not.

If you cannot tolerate this approach, may be we need to consider
implementing "(d) Calculate pathname while doing name resolution" approach.

Regards.
--
Subject: Call LSM functions outside VFS helper functions.

This patch allows LSM to check permission using "struct vfsmount"
without passing "struct vfsmount" to VFS helper functions.
There is a side effect that conventional permission checks are done twice
because I want to do DAC checks before MAC checks.

Signed-off-by:   Tetsuo Handa <[EMAIL PROTECTED]>
---
 fs/namei.c   |  176 ++-
 fs/open.c|   11 ++
 include/linux/fs.h   |1 
 include/linux/security.h |   63 
 net/unix/af_unix.c   |9 ++
 security/dummy.c |   17 
 security/security.c  |   15 
 7 files changed, 254 insertions(+), 38 deletions(-)

--- linux-2.6.25-rc2-mm1.orig/fs/namei.c
+++ linux-2.6.25-rc2-mm1/fs/namei.c
@@ -2015,18 +2015,24 @@ fail:
 }
 EXPORT_SYMBOL_GPL(lookup_create);
 
-int vfs_mknod(struct inode *dir, struct dentry *dentry, int mode, dev_t dev)
+int pre_vfs_mknod(struct inode *dir, struct dentry *dentry, int mode)
 {
int error = may_create(dir, dentry, NULL);
-
if (error)
return error;
-
if ((S_ISCHR(mode) || S_ISBLK(mode)) && !capable(CAP_MKNOD))
return -EPERM;
-
if (!dir->i_op || !dir->i_op->mknod)
return -EPERM;
+   return 0;
+}
+EXPORT_SYMBOL(pre_vfs_mknod);
+
+int vfs_mknod(struct inode *dir, struct dentry *dentry, int mode, dev_t dev)
+{
+   int error = pre_vfs_mknod(dir, dentry, mode);
+   if (error)
+   return error;
 
error = security_inode_mknod(dir, dentry, mode, dev);
if (error)
@@ -2087,14 +2093,39 @@ asmlinkage long sys_mknodat(int dfd, con
if (error)
goto out_dput;
switch (mode & S_IFMT) {
+   int type;
case 0: case S_IFREG:
error = 
vfs_create(nd.path.dentry->d_inode,dentry,mode,&nd);
break;
case S_IFCHR: case S_IFBLK:
+   error = pre_vfs_mknod(nd.path.dentry->d_inode, dentry,
+ mode);
+   if (error)
+   break;
+   if (S_ISCHR(mode))
+   type = TYPE_MKCHAR_ACL;
+   else
+   type = TYPE_MKBLOCK_ACL;
+   error = security_singlepath_permission(type, dentry,
+  nd.path.mnt);
+   if (error)
+   break;
error = vfs_mknod(nd.path.dentry->d_inode,dentry,mode,
new_decode_dev(dev));
break;
case S_IFIFO: case S_IFSOCK:
+   error = pre_vfs_mknod(nd.path.dentry->d_inode, dentry,
+ mode);
+   if (error)
+   break;
+   if (S_ISFIFO(mode))
+   type = TYPE_MKFIFO_ACL;
+   else
+   type = TYPE_MKSOCK_ACL;
+   error = security_singlepath_permission(type, dentry,
+  nd.path.mnt);
+   if (error)
+   break;
error = 
vfs_mknod(nd.path.dentry->d_inode,dentry,mode,0);
break;
}
@@ -2115,15 +2146,21 @@ asmlinkage long sys_mknod(const char __u
return sys_mknodat(AT_FDCWD, filename, mode, dev);
 }
 
-int vfs_mkdir(struct inode *dir, struct dentry *dentry, int mode)
+static inline int pre_vfs_mkdir(struct inode *dir, struct dentry *dentry)
 {
int error = may_create(dir, dentry, NULL);
-
if (error)
return error;
-
if (!dir->i_op || !dir->i_op->mkdir)
return -EPERM;
+   return 0;
+}
+
+int vfs_mkdir(struct inode *dir, struct dentry *dentry, int mode)
+{
+   int error = pre_vfs_mkdir(dir, dentry);
+   if (error)
+   return error;
 
mode &= (S_IRWXUGO|S_ISVTX);
error = security_inode_mkdir(dir, dentry, mode);
@@ -2162,7 +2199,12 @@ asmlinkage long sys_mkdirat(int dfd, con
error = mnt_want_write(nd.path.mnt);
if (error)
goto out_dput;
-   error = vfs_mkdir(nd.path.dentry->d_inode, dentry, mode);
+   error = pre_vfs_mkdir(nd.path.dentry->d_ino

Re: [RFC] Add vfsmount to vfs helper functions.

2008-02-02 Thread Tetsuo Handa 
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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Add vfsmount to vfs helper functions.

2008-01-30 Thread Al Viro 
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...
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC] Add vfsmount to vfs helper functions.

2008-01-25 Thread Kentaro Takeda 
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?

- Start of changes -
--- fs.h.orig
+++ fs.h
@@ -1070,13 +1070,13 @@
  */
 extern int vfs_permission(struct nameidata *, int);
 extern int vfs_create(struct inode *, struct dentry *, int, struct nameidata 
*);
-extern int vfs_mkdir(struct inode *, struct dentry *, int);
-extern int vfs_mknod(struct inode *, struct dentry *, int, dev_t);
-extern int vfs_symlink(struct inode *, struct dentry *, const char *, int);
-extern int vfs_link(struct dentry *, struct inode *, struct dentry *);
-extern int vfs_rmdir(struct inode *, struct dentry *);
-extern int vfs_unlink(struct inode *, struct dentry *);
-extern int vfs_rename(struct inode *, struct dentry *, struct inode *, struct 
dentry *);
+extern int vfs_mkdir(struct inode *, struct dentry *, struct vfsmount *, int);
+extern int vfs_mknod(struct inode *, struct dentry *, struct vfsmount *, int, 
dev_t);
+extern int vfs_symlink(struct inode *, struct dentry *, struct vfsmount *, 
const char *, int);
+extern int vfs_link(struct dentry *, struct vfsmount *, struct inode *, struct 
dentry *, struct vfsmount *);
+extern int vfs_rmdir(struct inode *, struct dentry *, struct vfsmount *);
+extern int vfs_unlink(struct inode *, struct dentry *, struct vfsmount *);
+extern int vfs_rename(struct inode *, struct dentry *, struct vfsmount *, 
struct inode *, struct dentry *, struct vfsmount *);
 
 /*
  * VFS dentry helper functions.
@@ -1538,8 +1538,8 @@
 
 /* fs/open.c */
 
-extern int do_truncate(struct dentry *, loff_t start, unsigned int time_attrs,
-  struct file *filp);
+extern int do_truncate(struct dentry *, struct vfsmount *, loff_t start,
+  unsigned int time_attrs, struct file *filp);
 extern long do_sys_open(int dfd, const char __user *filename, int flags,
int mode);
 extern struct file * dentry_open(struct dentry *, struct vfsmount *, int);
@@ -1695,7 +1695,7 @@
 #ifdef CONFIG_BLOCK
 extern sector_t bmap(struct inode *, sector_t);
 #endif
-extern int notify_change(struct dentry *, struct iattr *);
+extern int notify_change(struct dentry *, struct vfsmount *, struct iattr *);
 extern int permission(struct inode *, int, struct nameidata *);
 extern int generic_permission(struct inode *, int,
int (*check_acl)(struct inode *, int));
@@ -1757,9 +1757,9 @@
 extern void clear_inode(struct inode *);
 extern void destroy_inode(struct inode *);
 extern struct inode *new_inode(struct super_block *);
-extern int __remove_suid(struct dentry *, int);
+extern int __remove_suid(struct path *, int);
 extern int should_remove_suid(struct dentry *);
-extern int remove_suid(struct dentry *);
+extern int remove_suid(struct path *);
 
 extern void __insert_inode_hash(struct inode *, unsigned long hashval);
 extern void remove_inode_hash(struct inode *);
- End of changes -

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html