Re: [patch 7/8] allow unprivileged mounts
> > On Apr 21 2007 10:57, Eric W. Biederman wrote: > >> > >>> tmpfs! > >> > >>tmpfs is a possible problem because it can consume lots of ram/swap. > >>Which is why it has limits on the amount of space it can consume. > > > > Users can gobble up all RAM and swap already today. (Unless they are > > confined into an rlimit, which, in most systems, is not the case.) > > And in case /dev/shm exists, they can already fill it without running > > into an rlimit early. > > There are systems that care about rlimits and there is strong intersection > between caring about rlimits and user mounts. Although I do agree that > it looks like we have gotten lazy with the default mount options for > /dev/shm. > > Going a little farther any filesystem that is safe to put on a usb > stick and mount automatically should ultimately be safe for unprivileged > mounts as well. Actually, that's not as simple. For the usb stick or cdrom you need physical access to the machine. And once you have that you basically have full control over the system anyway. But with block filesystems, the user would still need access to the device (currently kernel doesn't even check this I think). So it may make sense to mark all block based filesystems safe, and defer permission checking to user access on the block device. But the safe flag is still needed for filesystems, which don't have such an additional access checking, such as network filesystems. Miklos - 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/
Re: [patch 7/8] allow unprivileged mounts
On Apr 21 2007 10:57, Eric W. Biederman wrote: tmpfs! tmpfs is a possible problem because it can consume lots of ram/swap. Which is why it has limits on the amount of space it can consume. Users can gobble up all RAM and swap already today. (Unless they are confined into an rlimit, which, in most systems, is not the case.) And in case /dev/shm exists, they can already fill it without running into an rlimit early. There are systems that care about rlimits and there is strong intersection between caring about rlimits and user mounts. Although I do agree that it looks like we have gotten lazy with the default mount options for /dev/shm. Going a little farther any filesystem that is safe to put on a usb stick and mount automatically should ultimately be safe for unprivileged mounts as well. Actually, that's not as simple. For the usb stick or cdrom you need physical access to the machine. And once you have that you basically have full control over the system anyway. But with block filesystems, the user would still need access to the device (currently kernel doesn't even check this I think). So it may make sense to mark all block based filesystems safe, and defer permission checking to user access on the block device. But the safe flag is still needed for filesystems, which don't have such an additional access checking, such as network filesystems. Miklos - 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/
Re: [patch 7/8] allow unprivileged mounts
Andrew Morton wrote: On Fri, 20 Apr 2007 12:25:39 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote: Define a new fs flag FS_SAFE, which denotes, that unprivileged mounting of this filesystem may not constitute a security problem. Since most filesystems haven't been designed with unprivileged mounting in mind, a thorough audit is needed before setting this flag. Practically speaking, is there any realistic likelihood that any filesystem apart from FUSE will ever use this? Would it be interesting to support mounting of external file systems (be it USB, NFS or whatever) in a way that automatically forces it to ignore suid and devices (which are already mount time options)? The question I guess is, how much do you gain over a setuid program (hack?) that can handle this? - 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/
Re: [patch 7/8] allow unprivileged mounts
Andi Kleen <[EMAIL PROTECTED]> writes: > Andrew Morton <[EMAIL PROTECTED]> writes: > >> On Fri, 20 Apr 2007 12:25:39 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote: >> >> > Define a new fs flag FS_SAFE, which denotes, that unprivileged >> > mounting of this filesystem may not constitute a security problem. >> > >> > Since most filesystems haven't been designed with unprivileged >> > mounting in mind, a thorough audit is needed before setting this flag. >> >> Practically speaking, is there any realistic likelihood that any filesystem >> apart from FUSE will ever use this? > > If it worked for mount --bind for any fs I could see uses of this. I haven't > thought > through the security implications though, so it might not work. Binding a directory that you have access to in other was is essentially the same thing as a symlink. So there are no real security implications there. The only problem case I can think of is removal media that you want to remove but someone has made a bind mount to. But that is essentially the same case as opening a file so there are no new real issues. Although our diagnostic tools will likely fall behind for a bit. We handle the security implications by assigning an owner to all mounts and only allowing you to add additional mounts on top of a mount you already own. If you have the right capabilities you can create a mount owned by another user. For a new mount if you don't have the appropriate capabilities nodev and nosuid will be forced. Initial super block creation is a lot more delicate so we need the FS_SAFE flag, to know that the kernel is prepared to deal with the crazy things that a hostile user space is prepared to do. Eric - 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/
Re: [patch 7/8] allow unprivileged mounts
Andrew Morton <[EMAIL PROTECTED]> writes: > On Fri, 20 Apr 2007 12:25:39 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > > Define a new fs flag FS_SAFE, which denotes, that unprivileged > > mounting of this filesystem may not constitute a security problem. > > > > Since most filesystems haven't been designed with unprivileged > > mounting in mind, a thorough audit is needed before setting this flag. > > Practically speaking, is there any realistic likelihood that any filesystem > apart from FUSE will ever use this? If it worked for mount --bind for any fs I could see uses of this. I haven't thought through the security implications though, so it might not work. -Andi - 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/
Re: [patch 7/8] allow unprivileged mounts
Jan Engelhardt <[EMAIL PROTECTED]> writes: > On Apr 21 2007 10:57, Eric W. Biederman wrote: >> >>> tmpfs! >> >>tmpfs is a possible problem because it can consume lots of ram/swap. >>Which is why it has limits on the amount of space it can consume. > > Users can gobble up all RAM and swap already today. (Unless they are > confined into an rlimit, which, in most systems, is not the case.) > And in case /dev/shm exists, they can already fill it without running > into an rlimit early. There are systems that care about rlimits and there is strong intersection between caring about rlimits and user mounts. Although I do agree that it looks like we have gotten lazy with the default mount options for /dev/shm. Going a little farther any filesystem that is safe to put on a usb stick and mount automatically should ultimately be safe for unprivileged mounts as well. So it looks to me like ultimately most of the common filesystems will actually be safe for non-privileged mounting. Regardless this looks like an important discussion as soon as we have the glitches out of the non-privileged mount code. Eric - 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/
Re: [patch 7/8] allow unprivileged mounts
On Apr 21 2007 10:57, Eric W. Biederman wrote: > >> tmpfs! > >tmpfs is a possible problem because it can consume lots of ram/swap. >Which is why it has limits on the amount of space it can consume. Users can gobble up all RAM and swap already today. (Unless they are confined into an rlimit, which, in most systems, is not the case.) And in case /dev/shm exists, they can already fill it without running into an rlimit early. >Those are set as mount options as I recall. Which means that we >would need to do something different with respect to limits before >tmpfs could become safe for an untrusted user to mount. > >Still it's close. Jan -- - 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/
Re: [patch 7/8] allow unprivileged mounts
Jan Engelhardt <[EMAIL PROTECTED]> writes: > On Apr 21 2007 08:10, Eric W. Biederman wrote: >>> Define a new fs flag FS_SAFE, which denotes, that unprivileged mounting of this filesystem may not constitute a security problem. Since most filesystems haven't been designed with unprivileged mounting in mind, a thorough audit is needed before setting this flag. >>> >>> Practically speaking, is there any realistic likelihood that any filesystem >>> apart from FUSE will ever use this? >> >>Also potentially some of the kernel virtual filesystems. /proc should >>be safe already. If you don't have any kind of backing store this problem >>gets easier. > > tmpfs! tmpfs is a possible problem because it can consume lots of ram/swap. Which is why it has limits on the amount of space it can consume. Those are set as mount options as I recall. Which means that we would need to do something different with respect to limits before tmpfs could become safe for an untrusted user to mount. Still it's close. Eric - 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/
Re: [patch 7/8] allow unprivileged mounts
On Apr 21 2007 08:10, Eric W. Biederman wrote: >> >>> Define a new fs flag FS_SAFE, which denotes, that unprivileged >>> mounting of this filesystem may not constitute a security problem. >>> >>> Since most filesystems haven't been designed with unprivileged >>> mounting in mind, a thorough audit is needed before setting this flag. >> >> Practically speaking, is there any realistic likelihood that any filesystem >> apart from FUSE will ever use this? > >Also potentially some of the kernel virtual filesystems. /proc should >be safe already. If you don't have any kind of backing store this problem >gets easier. tmpfs! Jan -- - 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/
Re: [patch 7/8] allow unprivileged mounts
Andrew Morton <[EMAIL PROTECTED]> writes: > On Fri, 20 Apr 2007 12:25:39 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote: > >> Define a new fs flag FS_SAFE, which denotes, that unprivileged >> mounting of this filesystem may not constitute a security problem. >> >> Since most filesystems haven't been designed with unprivileged >> mounting in mind, a thorough audit is needed before setting this flag. > > Practically speaking, is there any realistic likelihood that any filesystem > apart from FUSE will ever use this? Also potentially some of the kernel virtual filesystems. /proc should be safe already. If you don't have any kind of backing store this problem gets easier. With unprivileged users allowed to create mounts the utility of kernel functionality exported as filesystems goes up quite a bit. We are not plan9 but this is the last bottleneck in allowing the everything is a filesystem paradigm from being really usable in linux. Eric - 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/
Re: [patch 7/8] allow unprivileged mounts
> > > > > Define a new fs flag FS_SAFE, which denotes, that unprivileged > > > mounting of this filesystem may not constitute a security problem. > > > > > > Since most filesystems haven't been designed with unprivileged > > > mounting in mind, a thorough audit is needed before setting this flag. > > > > Practically speaking, is there any realistic likelihood that any filesystem > > apart from FUSE will ever use this? > > V9FS people did express an interest in this. Yeah, I should've CC-ed > them, but forgot. Sorry. And CIFS maybe. They also have an unprivileged mounting suid hack. But I'm not very optimistic about CIFS, seeing some of the code, that's in there. Miklos - 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/
Re: [patch 7/8] allow unprivileged mounts
> On Fri, 20 Apr 2007 12:25:39 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > > Define a new fs flag FS_SAFE, which denotes, that unprivileged > > mounting of this filesystem may not constitute a security problem. > > > > Since most filesystems haven't been designed with unprivileged > > mounting in mind, a thorough audit is needed before setting this flag. > > Practically speaking, is there any realistic likelihood that any filesystem > apart from FUSE will ever use this? V9FS people did express an interest in this. Yeah, I should've CC-ed them, but forgot. Sorry. Miklos - 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/
Re: [patch 7/8] allow unprivileged mounts
On Fri, 20 Apr 2007 12:25:39 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote: > Define a new fs flag FS_SAFE, which denotes, that unprivileged > mounting of this filesystem may not constitute a security problem. > > Since most filesystems haven't been designed with unprivileged > mounting in mind, a thorough audit is needed before setting this flag. Practically speaking, is there any realistic likelihood that any filesystem apart from FUSE will ever use this? - 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/
Re: [patch 7/8] allow unprivileged mounts
On Fri, 20 Apr 2007 12:25:39 +0200 Miklos Szeredi [EMAIL PROTECTED] wrote: Define a new fs flag FS_SAFE, which denotes, that unprivileged mounting of this filesystem may not constitute a security problem. Since most filesystems haven't been designed with unprivileged mounting in mind, a thorough audit is needed before setting this flag. Practically speaking, is there any realistic likelihood that any filesystem apart from FUSE will ever use this? - 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/
Re: [patch 7/8] allow unprivileged mounts
On Fri, 20 Apr 2007 12:25:39 +0200 Miklos Szeredi [EMAIL PROTECTED] wrote: Define a new fs flag FS_SAFE, which denotes, that unprivileged mounting of this filesystem may not constitute a security problem. Since most filesystems haven't been designed with unprivileged mounting in mind, a thorough audit is needed before setting this flag. Practically speaking, is there any realistic likelihood that any filesystem apart from FUSE will ever use this? V9FS people did express an interest in this. Yeah, I should've CC-ed them, but forgot. Sorry. Miklos - 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/
Re: [patch 7/8] allow unprivileged mounts
Define a new fs flag FS_SAFE, which denotes, that unprivileged mounting of this filesystem may not constitute a security problem. Since most filesystems haven't been designed with unprivileged mounting in mind, a thorough audit is needed before setting this flag. Practically speaking, is there any realistic likelihood that any filesystem apart from FUSE will ever use this? V9FS people did express an interest in this. Yeah, I should've CC-ed them, but forgot. Sorry. And CIFS maybe. They also have an unprivileged mounting suid hack. But I'm not very optimistic about CIFS, seeing some of the code, that's in there. Miklos - 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/
Re: [patch 7/8] allow unprivileged mounts
Andrew Morton [EMAIL PROTECTED] writes: On Fri, 20 Apr 2007 12:25:39 +0200 Miklos Szeredi [EMAIL PROTECTED] wrote: Define a new fs flag FS_SAFE, which denotes, that unprivileged mounting of this filesystem may not constitute a security problem. Since most filesystems haven't been designed with unprivileged mounting in mind, a thorough audit is needed before setting this flag. Practically speaking, is there any realistic likelihood that any filesystem apart from FUSE will ever use this? Also potentially some of the kernel virtual filesystems. /proc should be safe already. If you don't have any kind of backing store this problem gets easier. With unprivileged users allowed to create mounts the utility of kernel functionality exported as filesystems goes up quite a bit. We are not plan9 but this is the last bottleneck in allowing the everything is a filesystem paradigm from being really usable in linux. Eric - 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/
Re: [patch 7/8] allow unprivileged mounts
On Apr 21 2007 08:10, Eric W. Biederman wrote: Define a new fs flag FS_SAFE, which denotes, that unprivileged mounting of this filesystem may not constitute a security problem. Since most filesystems haven't been designed with unprivileged mounting in mind, a thorough audit is needed before setting this flag. Practically speaking, is there any realistic likelihood that any filesystem apart from FUSE will ever use this? Also potentially some of the kernel virtual filesystems. /proc should be safe already. If you don't have any kind of backing store this problem gets easier. tmpfs! Jan -- - 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/
Re: [patch 7/8] allow unprivileged mounts
Jan Engelhardt [EMAIL PROTECTED] writes: On Apr 21 2007 08:10, Eric W. Biederman wrote: Define a new fs flag FS_SAFE, which denotes, that unprivileged mounting of this filesystem may not constitute a security problem. Since most filesystems haven't been designed with unprivileged mounting in mind, a thorough audit is needed before setting this flag. Practically speaking, is there any realistic likelihood that any filesystem apart from FUSE will ever use this? Also potentially some of the kernel virtual filesystems. /proc should be safe already. If you don't have any kind of backing store this problem gets easier. tmpfs! tmpfs is a possible problem because it can consume lots of ram/swap. Which is why it has limits on the amount of space it can consume. Those are set as mount options as I recall. Which means that we would need to do something different with respect to limits before tmpfs could become safe for an untrusted user to mount. Still it's close. Eric - 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/
Re: [patch 7/8] allow unprivileged mounts
On Apr 21 2007 10:57, Eric W. Biederman wrote: tmpfs! tmpfs is a possible problem because it can consume lots of ram/swap. Which is why it has limits on the amount of space it can consume. Users can gobble up all RAM and swap already today. (Unless they are confined into an rlimit, which, in most systems, is not the case.) And in case /dev/shm exists, they can already fill it without running into an rlimit early. Those are set as mount options as I recall. Which means that we would need to do something different with respect to limits before tmpfs could become safe for an untrusted user to mount. Still it's close. Jan -- - 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/
Re: [patch 7/8] allow unprivileged mounts
Jan Engelhardt [EMAIL PROTECTED] writes: On Apr 21 2007 10:57, Eric W. Biederman wrote: tmpfs! tmpfs is a possible problem because it can consume lots of ram/swap. Which is why it has limits on the amount of space it can consume. Users can gobble up all RAM and swap already today. (Unless they are confined into an rlimit, which, in most systems, is not the case.) And in case /dev/shm exists, they can already fill it without running into an rlimit early. There are systems that care about rlimits and there is strong intersection between caring about rlimits and user mounts. Although I do agree that it looks like we have gotten lazy with the default mount options for /dev/shm. Going a little farther any filesystem that is safe to put on a usb stick and mount automatically should ultimately be safe for unprivileged mounts as well. So it looks to me like ultimately most of the common filesystems will actually be safe for non-privileged mounting. Regardless this looks like an important discussion as soon as we have the glitches out of the non-privileged mount code. Eric - 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/
Re: [patch 7/8] allow unprivileged mounts
Andrew Morton [EMAIL PROTECTED] writes: On Fri, 20 Apr 2007 12:25:39 +0200 Miklos Szeredi [EMAIL PROTECTED] wrote: Define a new fs flag FS_SAFE, which denotes, that unprivileged mounting of this filesystem may not constitute a security problem. Since most filesystems haven't been designed with unprivileged mounting in mind, a thorough audit is needed before setting this flag. Practically speaking, is there any realistic likelihood that any filesystem apart from FUSE will ever use this? If it worked for mount --bind for any fs I could see uses of this. I haven't thought through the security implications though, so it might not work. -Andi - 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/
Re: [patch 7/8] allow unprivileged mounts
Andi Kleen [EMAIL PROTECTED] writes: Andrew Morton [EMAIL PROTECTED] writes: On Fri, 20 Apr 2007 12:25:39 +0200 Miklos Szeredi [EMAIL PROTECTED] wrote: Define a new fs flag FS_SAFE, which denotes, that unprivileged mounting of this filesystem may not constitute a security problem. Since most filesystems haven't been designed with unprivileged mounting in mind, a thorough audit is needed before setting this flag. Practically speaking, is there any realistic likelihood that any filesystem apart from FUSE will ever use this? If it worked for mount --bind for any fs I could see uses of this. I haven't thought through the security implications though, so it might not work. Binding a directory that you have access to in other was is essentially the same thing as a symlink. So there are no real security implications there. The only problem case I can think of is removal media that you want to remove but someone has made a bind mount to. But that is essentially the same case as opening a file so there are no new real issues. Although our diagnostic tools will likely fall behind for a bit. We handle the security implications by assigning an owner to all mounts and only allowing you to add additional mounts on top of a mount you already own. If you have the right capabilities you can create a mount owned by another user. For a new mount if you don't have the appropriate capabilities nodev and nosuid will be forced. Initial super block creation is a lot more delicate so we need the FS_SAFE flag, to know that the kernel is prepared to deal with the crazy things that a hostile user space is prepared to do. Eric - 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/
Re: [patch 7/8] allow unprivileged mounts
Andrew Morton wrote: On Fri, 20 Apr 2007 12:25:39 +0200 Miklos Szeredi [EMAIL PROTECTED] wrote: Define a new fs flag FS_SAFE, which denotes, that unprivileged mounting of this filesystem may not constitute a security problem. Since most filesystems haven't been designed with unprivileged mounting in mind, a thorough audit is needed before setting this flag. Practically speaking, is there any realistic likelihood that any filesystem apart from FUSE will ever use this? Would it be interesting to support mounting of external file systems (be it USB, NFS or whatever) in a way that automatically forces it to ignore suid and devices (which are already mount time options)? The question I guess is, how much do you gain over a setuid program (hack?) that can handle this? - 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/
[patch 7/8] allow unprivileged mounts
From: Miklos Szeredi <[EMAIL PROTECTED]>
Define a new fs flag FS_SAFE, which denotes, that unprivileged
mounting of this filesystem may not constitute a security problem.
Since most filesystems haven't been designed with unprivileged
mounting in mind, a thorough audit is needed before setting this flag.
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
---
Index: linux/fs/namespace.c
===
--- linux.orig/fs/namespace.c 2007-04-20 11:55:10.0 +0200
+++ linux/fs/namespace.c2007-04-20 11:55:13.0 +0200
@@ -781,13 +781,17 @@ asmlinkage long sys_oldumount(char __use
* - mountpoint is not a symlink or special file
* - mountpoint is in a mount owned by the user
*/
-static bool permit_mount(struct nameidata *nd, int *flags)
+static bool permit_mount(struct nameidata *nd, struct file_system_type *type,
+int *flags)
{
struct inode *inode = nd->dentry->d_inode;
if (capable(CAP_SYS_ADMIN))
return true;
+ if (type && !(type->fs_flags & FS_SAFE))
+ return false;
+
if (!S_ISDIR(inode->i_mode) && !S_ISREG(inode->i_mode))
return false;
@@ -1021,7 +1025,7 @@ static int do_loopback(struct nameidata
struct vfsmount *mnt = NULL;
int err;
- if (!permit_mount(nd, ))
+ if (!permit_mount(nd, NULL, ))
return -EPERM;
if (!old_name || !*old_name)
return -EINVAL;
@@ -1182,26 +1186,46 @@ out:
* create a new mount for userspace and request it to be added into the
* namespace's tree
*/
-static int do_new_mount(struct nameidata *nd, char *type, int flags,
+static int do_new_mount(struct nameidata *nd, char *fstype, int flags,
int mnt_flags, char *name, void *data)
{
+ int err;
struct vfsmount *mnt;
+ struct file_system_type *type;
- if (!type || !memchr(type, 0, PAGE_SIZE))
+ if (!fstype || !memchr(fstype, 0, PAGE_SIZE))
return -EINVAL;
- /* we need capabilities... */
- if (!capable(CAP_SYS_ADMIN))
- return -EPERM;
-
- mnt = do_kern_mount(type, flags & ~MS_SETUSER, name, data);
- if (IS_ERR(mnt))
+ type = get_fs_type(fstype);
+ if (!type)
+ return -ENODEV;
+
+ err = -EPERM;
+ if (!permit_mount(nd, type, ))
+ goto out_put_filesystem;
+
+ if (flags & MS_SETUSER) {
+ err = reserve_user_mount();
+ if (err)
+ goto out_put_filesystem;
+ }
+
+ mnt = vfs_kern_mount(type, flags & ~MS_SETUSER, name, data);
+ put_filesystem(type);
+ if (IS_ERR(mnt)) {
+ if (flags & MS_SETUSER)
+ dec_nr_user_mounts();
return PTR_ERR(mnt);
+ }
if (flags & MS_SETUSER)
- set_mnt_user(mnt);
+ __set_mnt_user(mnt);
return do_add_mount(mnt, nd, mnt_flags, NULL);
+
+ out_put_filesystem:
+ put_filesystem(type);
+ return err;
}
/*
@@ -1231,7 +1255,7 @@ int do_add_mount(struct vfsmount *newmnt
if (S_ISLNK(newmnt->mnt_root->d_inode->i_mode))
goto unlock;
- /* MNT_USER was set earlier */
+ /* some flags may have been set earlier */
newmnt->mnt_flags |= mnt_flags;
if ((err = graft_tree(newmnt, nd)))
goto unlock;
Index: linux/include/linux/fs.h
===
--- linux.orig/include/linux/fs.h 2007-04-20 11:55:11.0 +0200
+++ linux/include/linux/fs.h2007-04-20 11:55:13.0 +0200
@@ -96,6 +96,7 @@ extern int dir_notify_enable;
#define FS_REQUIRES_DEV 1
#define FS_BINARY_MOUNTDATA 2
#define FS_HAS_SUBTYPE 4
+#define FS_SAFE 8 /* Safe to mount by unprivileged users */
#define FS_REVAL_DOT 16384 /* Check the paths ".", ".." for staleness */
#define FS_RENAME_DOES_D_MOVE 32768 /* FS will handle d_move()
* during rename() internally.
--
-
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/
[patch 7/8] allow unprivileged mounts
From: Miklos Szeredi [EMAIL PROTECTED]
Define a new fs flag FS_SAFE, which denotes, that unprivileged
mounting of this filesystem may not constitute a security problem.
Since most filesystems haven't been designed with unprivileged
mounting in mind, a thorough audit is needed before setting this flag.
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
---
Index: linux/fs/namespace.c
===
--- linux.orig/fs/namespace.c 2007-04-20 11:55:10.0 +0200
+++ linux/fs/namespace.c2007-04-20 11:55:13.0 +0200
@@ -781,13 +781,17 @@ asmlinkage long sys_oldumount(char __use
* - mountpoint is not a symlink or special file
* - mountpoint is in a mount owned by the user
*/
-static bool permit_mount(struct nameidata *nd, int *flags)
+static bool permit_mount(struct nameidata *nd, struct file_system_type *type,
+int *flags)
{
struct inode *inode = nd-dentry-d_inode;
if (capable(CAP_SYS_ADMIN))
return true;
+ if (type !(type-fs_flags FS_SAFE))
+ return false;
+
if (!S_ISDIR(inode-i_mode) !S_ISREG(inode-i_mode))
return false;
@@ -1021,7 +1025,7 @@ static int do_loopback(struct nameidata
struct vfsmount *mnt = NULL;
int err;
- if (!permit_mount(nd, flags))
+ if (!permit_mount(nd, NULL, flags))
return -EPERM;
if (!old_name || !*old_name)
return -EINVAL;
@@ -1182,26 +1186,46 @@ out:
* create a new mount for userspace and request it to be added into the
* namespace's tree
*/
-static int do_new_mount(struct nameidata *nd, char *type, int flags,
+static int do_new_mount(struct nameidata *nd, char *fstype, int flags,
int mnt_flags, char *name, void *data)
{
+ int err;
struct vfsmount *mnt;
+ struct file_system_type *type;
- if (!type || !memchr(type, 0, PAGE_SIZE))
+ if (!fstype || !memchr(fstype, 0, PAGE_SIZE))
return -EINVAL;
- /* we need capabilities... */
- if (!capable(CAP_SYS_ADMIN))
- return -EPERM;
-
- mnt = do_kern_mount(type, flags ~MS_SETUSER, name, data);
- if (IS_ERR(mnt))
+ type = get_fs_type(fstype);
+ if (!type)
+ return -ENODEV;
+
+ err = -EPERM;
+ if (!permit_mount(nd, type, flags))
+ goto out_put_filesystem;
+
+ if (flags MS_SETUSER) {
+ err = reserve_user_mount();
+ if (err)
+ goto out_put_filesystem;
+ }
+
+ mnt = vfs_kern_mount(type, flags ~MS_SETUSER, name, data);
+ put_filesystem(type);
+ if (IS_ERR(mnt)) {
+ if (flags MS_SETUSER)
+ dec_nr_user_mounts();
return PTR_ERR(mnt);
+ }
if (flags MS_SETUSER)
- set_mnt_user(mnt);
+ __set_mnt_user(mnt);
return do_add_mount(mnt, nd, mnt_flags, NULL);
+
+ out_put_filesystem:
+ put_filesystem(type);
+ return err;
}
/*
@@ -1231,7 +1255,7 @@ int do_add_mount(struct vfsmount *newmnt
if (S_ISLNK(newmnt-mnt_root-d_inode-i_mode))
goto unlock;
- /* MNT_USER was set earlier */
+ /* some flags may have been set earlier */
newmnt-mnt_flags |= mnt_flags;
if ((err = graft_tree(newmnt, nd)))
goto unlock;
Index: linux/include/linux/fs.h
===
--- linux.orig/include/linux/fs.h 2007-04-20 11:55:11.0 +0200
+++ linux/include/linux/fs.h2007-04-20 11:55:13.0 +0200
@@ -96,6 +96,7 @@ extern int dir_notify_enable;
#define FS_REQUIRES_DEV 1
#define FS_BINARY_MOUNTDATA 2
#define FS_HAS_SUBTYPE 4
+#define FS_SAFE 8 /* Safe to mount by unprivileged users */
#define FS_REVAL_DOT 16384 /* Check the paths ., .. for staleness */
#define FS_RENAME_DOES_D_MOVE 32768 /* FS will handle d_move()
* during rename() internally.
--
-
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/
