OpenVZ Forum - RDF feed
type: channel
items: Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
items: Re: Re: [patch 05/10] add "permit user mounts in new namespace" clone flag

Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
type: item
description: Quoting Miklos Szeredi (miklos@szeredi.hu): > From: Miklos Szeredi <mszeredi@suse.cz> > > If CLONE_NEWNS and CLONE_NEWNS_USERMNT are given to clone(2) or > unshare(2), then allow user mounts within the new namespace. > > This is not flexible enough, because user mounts can't be enabled for > the initial namespace. > > The remaining clone bits also getting dangerously few... > > Alternatives are: > > - prctl() flag > - setting through the containers filesystem Sorry, I know I had mentioned it, but this is definately my least favorite approach. Curious whether are any other suggestions/opinions from the containers list? thanks, -serge > Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> > --- > > Index: linux/fs/namespace.c > =================================================================== > --- linux.orig/fs/namespace.c 2007-04-12 13:46:19.000000000 +0200 > +++ linux/fs/namespace.c 2007-04-12 13:54:36.000000000 +0200 > @@ -1617,6 +1617,8 @@ struct mnt_namespace *copy_mnt_ns(int fl > return ns; > > new_ns = dup_mnt_ns(ns, new_fs); > + if (new_ns && (flags & CLONE_NEWNS_USERMNT)) > + new_ns->flags |= MNT_NS_PERMIT_USERMOUNTS; > > put_mnt_ns(ns); > return new_ns; > Index: linux/include/linux/sched.h > =================================================================== > --- linux.orig/include/linux/sched.h 2007-04-12 13:26:48.000000000 +0200 > +++ linux/include/linux/sched.h 2007-04-12 13:54:36.000000000 +0200 > @@ -26,6 +26,7 @@ > #define CLONE_STOPPED 0x02000000 /* Start in stopped state */ > #define CLONE_NEWUTS 0x04000000 /* New utsname group? */ > #define CLONE_NEWIPC 0x08000000 /* New ipcs */ > +#define CLONE_NEWNS_USERMNT 0x10000000 /* Allow user mounts in ns? */ > > /* > * Scheduling policies > Index: linux/kernel/fork.c > =================================================================== > --- linux.orig/kernel/fork.c 2007-04-11 18:27:46.000000000 +0200 > +++ linux/kernel/fork.c 2007-04-12 13:59:10.000000000 +0200 > @@ -1586,7 +1586,7 @@ asmlinkage long sys_u…
creator: serue
date: 2007-04-12T20:32:08-00:00

Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
type: item
description: On Thu, Apr 12, 2007 at 03:32:08PM -0500, Serge E. Hallyn wrote: > Quoting Miklos Szeredi (miklos@szeredi.hu): > > From: Miklos Szeredi <mszeredi@suse.cz> > > > > If CLONE_NEWNS and CLONE_NEWNS_USERMNT are given to clone(2) or > > unshare(2), then allow user mounts within the new namespace. > > This is not flexible enough, because user mounts can't be enabled for > > the initial namespace. > > > > The remaining clone bits also getting dangerously few... ATM I think we do not have that many CLONE flags available, so that this feature will have to wait for a clone2/64 or similar ... > > Alternatives are: > > > > - prctl() flag > > - setting through the containers filesystem > Sorry, I know I had mentioned it, but this is definately my least > favorite approach. > > Curious whether are any other suggestions/opinions from the containers > list? question: how is mounting filesystems (loopback, fuse, etc) secured in such way that the user cannot 'create' device nodes with 'unfortunate' permissions? TIA, Herbert > thanks, > -serge > > > Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> > > --- > > > > Index: linux/fs/namespace.c > > =================================================================== > > --- linux.orig/fs/namespace.c 2007-04-12 13:46:19.000000000 +0200 > > +++ linux/fs/namespace.c 2007-04-12 13:54:36.000000000 +0200 > > @@ -1617,6 +1617,8 @@ struct mnt_namespace *copy_mnt_ns(int fl > > return ns; > > > > new_ns = dup_mnt_ns(ns, new_fs); > > + if (new_ns && (flags & CLONE_NEWNS_USERMNT)) > > + new_ns->flags |= MNT_NS_PERMIT_USERMOUNTS; > > > > put_mnt_ns(ns); > > return new_ns; > > Index: linux/include/linux/sched.h > > =================================================================== > > --- linux.orig/include/linux/sched.h 2007-04-12 13:26:48.000000000 +0200 > > +++ linux/include/linux/sched.h 2007-04-12 13:54:36.000000000 +0200 > > @@ -26,6 +26,7 @@ > > #define CLONE_STOPPED 0x02000000 /* Start in stopped state */ > > #define CLONE_NEWUTS 0x04000000 /* N…
creator: Herbert Poetzl
date: 2007-04-13T04:16:12-00:00

Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
type: item
description: "Serge E. Hallyn" <serue@us.ibm.com> writes: > Quoting Miklos Szeredi (miklos@szeredi.hu): >> From: Miklos Szeredi <mszeredi@suse.cz> >> >> If CLONE_NEWNS and CLONE_NEWNS_USERMNT are given to clone(2) or >> unshare(2), then allow user mounts within the new namespace. >> >> This is not flexible enough, because user mounts can't be enabled for >> the initial namespace. >> >> The remaining clone bits also getting dangerously few... >> >> Alternatives are: >> >> - prctl() flag >> - setting through the containers filesystem > > Sorry, I know I had mentioned it, but this is definately my least > favorite approach. > > Curious whether are any other suggestions/opinions from the containers > list? Given the existence of shared subtrees allowing/denying this at the mount namespace level is silly and wrong. If we need more than just the filesystem permission checks can we make it a mount flag settable with mount and remount that allows non-privileged users the ability to create mount points under it in directories they have full read/write access to. I don't like the use of clone flags for this purpose but in this case the shared subtress are a much more fundamental reasons for not doing this at the namespace level. Eric _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: ebiederm
date: 2007-04-13T04:45:33-00:00

Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
type: item
description: > question: how is mounting filesystems (loopback, > fuse, etc) secured in such way that the user > cannot 'create' device nodes with 'unfortunate' > permissions? All unprivileged mounts have "nosuid,nodev" added to their options. Miklos _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Miklos Szeredi
date: 2007-04-13T07:09:54-00:00

Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
type: item
description: > Given the existence of shared subtrees allowing/denying this at the mount > namespace level is silly and wrong. > > If we need more than just the filesystem permission checks can we > make it a mount flag settable with mount and remount that allows > non-privileged users the ability to create mount points under it > in directories they have full read/write access to. OK, that makes sense. > I don't like the use of clone flags for this purpose but in this > case the shared subtress are a much more fundamental reasons for not > doing this at the namespace level. I'll drop the clone flag, and add a mount flag instead. Thanks, Miklos _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Miklos Szeredi
date: 2007-04-13T07:12:07-00:00

Re: Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
type: item
description: Miklos Szeredi <miklos@szeredi.hu> writes: >> > That depends. Current patches check the "unprivileged submounts >> > allowed under this mount" flag only on the requested mount and not on >> > the propagated mounts. Do you see a problem with this? >> >> I think privileges of this sort should propagate. If I read what you >> just said correctly if I have a private mount namespace I won't be able >> to mount anything unless when it was setup the unprivileged submount >> command was explicitly set. > > By design yes. Why is that a problem? It certainly doesn't match my intuition. Why are directory permissions not sufficient to allow/deny non-priveleged mounts? I don't understand that contention yet. I should probably go back and look and see how plan9 handles mount/unmount permissions. Plan9 gets away with a lot more because it doesn't have a suid bit and mount namespaces were always present, so they don't have backwards compatibility problems. My best guess at the moment is that plan9 treated mount/unmount as completely unprivileged and used the mount namespaces to limit the scope of what would be affected by a mount/unmount operation. I think that may be reasonable in linux as well but it will require the presence of a mount namespace to limit the affects of what a user can do. So short of a more thorough audit I believe the final semantics should be: - mount/unmount for non-priveleged processes should only be limited by the mount namespace and directory permissions. - CLONE_NEWNS should not be a privileged operation. What prevents us from allowing these things? - Unprivileged CLONE_NEWNS and unprivileged mounts needs resource accounting so we don't have a denial of service attack. - Unprivileged mounts must be limited to directories that we have permission to modify in a way that we could get the same effect as the mount or unmount operation in terms of what files are visible otherwise we can mess up SUID executables. - Anything else? There are user space issues such…
creator: ebiederm
date: 2007-04-16T19:16:48-00:00

Re: Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
type: item
description: Quoting Eric W. Biederman (ebiederm@xmission.com): > Miklos Szeredi <miklos@szeredi.hu> writes: > > >> > That depends. Current patches check the "unprivileged submounts > >> > allowed under this mount" flag only on the requested mount and not on > >> > the propagated mounts. Do you see a problem with this? > >> > >> I think privileges of this sort should propagate. If I read what you > >> just said correctly if I have a private mount namespace I won't be able > >> to mount anything unless when it was setup the unprivileged submount > >> command was explicitly set. > > > > By design yes. Why is that a problem? > > It certainly doesn't match my intuition. > > Why are directory permissions not sufficient to allow/deny non-priveleged mounts? > I don't understand that contention yet. The same scenarios laid out previously in this thread. I.e. 1. user hallyn does mount --bind / /home/hallyn/root 2. (...) 3. admin does "deluser hallyn" and deluser starts wiping out root Or, 1. user hallyn does mount --bind / /home/hallyn/root 2. backup daemon starts backing up /home/hallyn/root/home/hallyn/root/home... So we started down the path of forcing users to clone a new namespace before doing user mounts, which is what the clone flag was about. Using per-mount flags also suffices as you had pointed out, which is being done here. But directory permissions are inadequate. (Unless you want to tackle each problem legacy tool one at a time to remove problems - i.e. deluser should umount everything under /home/hallyn before deleting, backup should be spawned from it's own namespace cloned right after boot or just back up on one filesystem, etc.) -serge > I should probably go back and look and see how plan9 handles mount/unmount > permissions. Plan9 gets away with a lot more because it doesn't have > a suid bit and mount namespaces were always present, so they don't have > backwards compatibility problems. > > My best guess at the moment is that plan9 treated mount/unmount as > completely…
creator: serue
date: 2007-04-16T19:56:52-00:00

Re: Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
type: item
description: "Serge E. Hallyn" <serue@us.ibm.com> writes: >> >> Why are directory permissions not sufficient to allow/deny non-priveleged > mounts? >> I don't understand that contention yet. > > The same scenarios laid out previously in this thread. I.e. > > 1. user hallyn does mount --bind / /home/hallyn/root > 2. (...) > 3. admin does "deluser hallyn" > > and deluser starts wiping out root > > Or, > > 1. user hallyn does mount --bind / /home/hallyn/root > 2. backup daemon starts backing up /home/hallyn/root/home/hallyn/root/home... > > So we started down the path of forcing users to clone a new namespace > before doing user mounts, which is what the clone flag was about. Using > per-mount flags also suffices as you had pointed out, which is being > done here. But directory permissions are inadequate. Interesting.... So far even today these things can happen, however they are sufficiently unlikely the tools don't account for them. Once a hostile user can cause them things are more of a problem. > (Unless you want to tackle each problem legacy tool one at a time to > remove problems - i.e. deluser should umount everything under > /home/hallyn before deleting, backup should be spawned from it's own > namespace cloned right after boot or just back up on one filesystem, > etc.) I don't see a way that backup and deluser won't need to be modified to work properly in a system where non-priveleged mounts are allowed, at least they will need to account for /share. That said it is clearly a hazard if we enable this functionality by default. If we setup a pam module that triggers on login and perhaps when cron and at jobs run to setup an additional mount namespace I think keeping applications locked away in their own mount namespace is sufficient to avoid hostile users from doing unexpected things to the initial mount namespace. So unless I am mistake it should be relatively simple to prevent user space from encountering problems. That still leaves the question of how we handle systems wi…
creator: ebiederm
date: 2007-04-17T09:04:14-00:00

Re: Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
type: item
description: > Interesting.... > > So far even today these things can happen, however they are sufficiently > unlikely the tools don't account for them. > > Once a hostile user can cause them things are more of a problem. > > > (Unless you want to tackle each problem legacy tool one at a time to > > remove problems - i.e. deluser should umount everything under > > /home/hallyn before deleting, backup should be spawned from it's own > > namespace cloned right after boot or just back up on one filesystem, > > etc.) > > I don't see a way that backup and deluser won't need to be modified > to work properly in a system where non-priveleged mounts are allowed, > at least they will need to account for /share. > > That said it is clearly a hazard if we enable this functionality by > default. > > If we setup a pam module that triggers on login and perhaps when > cron and at jobs run to setup an additional mount namespace I think > keeping applications locked away in their own mount namespace is > sufficient to avoid hostile users from doing unexpected things to > the initial mount namespace. So unless I am mistake it should be > relatively simple to prevent user space from encountering problems. > > That still leaves the question of how we handle systems with an old > user space that is insufficiently robust to deal with mounts occurring > at unexpected locations. > > > I think a simple sysctl to enable/disable of non-priveleged mounts > defaulting to disabled is enough. > > Am I correct or will it be more difficult than just a little pam > module to ensure non-trusted users never run in the initial mount > namespace? I'm still not sure, what your problem is. With the v3 of the usermounts patchset, by default, user mounts are disabled, because the "allow unpriv submounts" flag is cleared on all mounts. There are several options available to sysadmins and distro builders to enable user mounts in a secure way: - pam module, which creates a private namespace, and sets "allow unpriv submount…
creator: Miklos Szeredi
date: 2007-04-17T11:09:25-00:00

Re: Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
type: item
description: Quoting Eric W. Biederman (ebiederm@xmission.com): > "Serge E. Hallyn" <serue@us.ibm.com> writes: > >> > >> Why are directory permissions not sufficient to allow/deny non-priveleged > > mounts? > >> I don't understand that contention yet. > > > > The same scenarios laid out previously in this thread. I.e. > > > > 1. user hallyn does mount --bind / /home/hallyn/root > > 2. (...) > > 3. admin does "deluser hallyn" > > > > and deluser starts wiping out root > > > > Or, > > > > 1. user hallyn does mount --bind / /home/hallyn/root > > 2. backup daemon starts backing up /home/hallyn/root/home/hallyn/root/home... > > > > So we started down the path of forcing users to clone a new namespace > > before doing user mounts, which is what the clone flag was about. Using > > per-mount flags also suffices as you had pointed out, which is being > > done here. But directory permissions are inadequate. > > Interesting.... > > So far even today these things can happen, however they are sufficiently > unlikely the tools don't account for them. > > Once a hostile user can cause them things are more of a problem. > > > (Unless you want to tackle each problem legacy tool one at a time to > > remove problems - i.e. deluser should umount everything under > > /home/hallyn before deleting, backup should be spawned from it's own > > namespace cloned right after boot or just back up on one filesystem, > > etc.) > > I don't see a way that backup and deluser won't need to be modified > to work properly in a system where non-priveleged mounts are allowed, > at least they will need to account for /share. Yes, all the tools need to avoid /share. Though at least it's a single location we can avoid, and it is purely a system configuration issue, whereas fixing deluser to watch for user mounts under /home involves (I assume) rewriting a part of it. > That said it is clearly a hazard if we enable this functionality by > default. > > If we setup a pam module that triggers on login and perhaps when > cron…
creator: serue
date: 2007-04-17T14:25:19-00:00

Re: Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
type: item
description: Quoting Eric W. Biederman (ebiederm@xmission.com): > "Serge E. Hallyn" <serue@us.ibm.com> writes: > >> > >> Why are directory permissions not sufficient to allow/deny non-priveleged > > mounts? > >> I don't understand that contention yet. > > > > The same scenarios laid out previously in this thread. I.e. > > > > 1. user hallyn does mount --bind / /home/hallyn/root > > 2. (...) > > 3. admin does "deluser hallyn" > > > > and deluser starts wiping out root > > > > Or, > > > > 1. user hallyn does mount --bind / /home/hallyn/root > > 2. backup daemon starts backing up /home/hallyn/root/home/hallyn/root/home... > > > > So we started down the path of forcing users to clone a new namespace > > before doing user mounts, which is what the clone flag was about. Using > > per-mount flags also suffices as you had pointed out, which is being > > done here. But directory permissions are inadequate. > > Interesting.... > > So far even today these things can happen, however they are sufficiently > unlikely the tools don't account for them. > > Once a hostile user can cause them things are more of a problem. > > > (Unless you want to tackle each problem legacy tool one at a time to > > remove problems - i.e. deluser should umount everything under > > /home/hallyn before deleting, backup should be spawned from it's own > > namespace cloned right after boot or just back up on one filesystem, > > etc.) > > I don't see a way that backup and deluser won't need to be modified > to work properly in a system where non-priveleged mounts are allowed, > at least they will need to account for /share. > > That said it is clearly a hazard if we enable this functionality by > default. > > If we setup a pam module that triggers on login and perhaps when > cron and at jobs run to setup an additional mount namespace I think > keeping applications locked away in their own mount namespace is > sufficient to avoid hostile users from doing unexpected things to > the initial mount namespace. So unless I a…
creator: serue
date: 2007-04-17T14:28:45-00:00

Re: Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
type: item
description: Miklos Szeredi <miklos@szeredi.hu> writes: > I'm still not sure, what your problem is. My problem right now is that I see a serious complexity escalation in the user interface that we must support indefinitely. I see us taking a nice powerful concept and seriously watering it down. To some extent we have to avoid confusing suid applications. (I would so love to remove the SUID bit...). I'm being contrary to ensure we have a good code review. I have heard it said that there are two kinds of design. Something so simple it obviously has no deficiencies. Something so complex it has no obvious deficiencies. I am very much afraid we are slipping the mount namespace into the latter category of work. Which is a bad bad thing for core OS feature. > With the v3 of the usermounts patchset, by default, user mounts are > disabled, because the "allow unpriv submounts" flag is cleared on all > mounts. > > There are several options available to sysadmins and distro builders > to enable user mounts in a secure way: > > - pam module, which creates a private namespace, and sets "allow > unpriv submounts" on the mounts within the namespace > > - pam module, which rbinds / onto /mnt/ns/$USER, and chroots into > /mnt/ns/$USER, then sets the "allow unpriv submounts" on the > mounts under /mnt/ns/$USER. In part this really disturbs me because we now have two mechanisms for controlling the scope of what a user can do. A flag or a new namespace. Two mechanisms to accomplish the same thing sound wrong, and hard to manage. > - sysadmin creates /mnt/usermounts writable to all users, with > sticky bit (same as /tmp), does "mount --bind /mnt/usermounts > /mnt/usermounts" and sets the "allow unpriv submounts" on > /mnt/usermounts. > > All of these are perfectly safe wrt userdel and backup (assuming it > doesn't try back up /mnt). I also don't understand at all the user= mount flag and options. All it seemed to be used for was adding permissions to unmount. In user space to deal with the lack of an…
creator: ebiederm
date: 2007-04-17T18:16:45-00:00

Re: Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
type: item
description: > > I'm still not sure, what your problem is. > > My problem right now is that I see a serious complexity escalation in > the user interface that we must support indefinitely. > > I see us taking a nice powerful concept and seriously watering it down. > To some extent we have to avoid confusing suid applications. (I would > so love to remove the SUID bit...). > > I'm being contrary to ensure we have a good code review. OK. And it's very much appreciated :) > I have heard it said that there are two kinds of design. Something > so simple it obviously has no deficiencies. Something so complex it has > no obvious deficiencies. I am very much afraid we are slipping the > mount namespace into the latter category of work. Which is a bad > bad thing for core OS feature. I've tried to make this unprivileged mount thing as simple as possible, and no simpler. If we can make it even simpler, all the better. > > With the v3 of the usermounts patchset, by default, user mounts are > > disabled, because the "allow unpriv submounts" flag is cleared on all > > mounts. > > > > There are several options available to sysadmins and distro builders > > to enable user mounts in a secure way: > > > > - pam module, which creates a private namespace, and sets "allow > > unpriv submounts" on the mounts within the namespace > > > > - pam module, which rbinds / onto /mnt/ns/$USER, and chroots into > > /mnt/ns/$USER, then sets the "allow unpriv submounts" on the > > mounts under /mnt/ns/$USER. > > In part this really disturbs me because we now have two mechanisms for > controlling the scope of what a user can do. You mean rbind+chroot and clone(CLONE_NS)? Yes, those are two different mechanisms achieving very similar results. But what has this to do with unprivileged mounts? > A flag or a new namespace. Two mechanisms to accomplish the same > thing sound wrong, and hard to manage. The flag permitting the unprivileged mounts (which we now agreed to name "allowusermnt") is used in both cases. Just …
creator: Miklos Szeredi
date: 2007-04-17T18:36:04-00:00

Re: Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
type: item
description: Miklos Szeredi <miklos@szeredi.hu> writes: >> > I'm still not sure, what your problem is. >> >> My problem right now is that I see a serious complexity escalation in >> the user interface that we must support indefinitely. >> >> I see us taking a nice powerful concept and seriously watering it down. >> To some extent we have to avoid confusing suid applications. (I would >> so love to remove the SUID bit...). >> >> I'm being contrary to ensure we have a good code review. > > OK. And it's very much appreciated :) > >> I have heard it said that there are two kinds of design. Something >> so simple it obviously has no deficiencies. Something so complex it has >> no obvious deficiencies. I am very much afraid we are slipping the >> mount namespace into the latter category of work. Which is a bad >> bad thing for core OS feature. > > I've tried to make this unprivileged mount thing as simple as > possible, and no simpler. If we can make it even simpler, all the > better. We are certainly much more complex then the code in plan9 (just read through it) so I think we have room for improvement. Just for reference what I saw in plan 9 was: - No super user checks in it's mount, unmount, or namespace creation paths. - A flag to deny new mounts but not new bind mounts (for administrative purposes the comment said). Our differences from plan9. - suid capable binaries. (SUID please go away). - A history of programs assuming only root could call mount/unmount. >> In part this really disturbs me because we now have two mechanisms for >> controlling the scope of what a user can do. > > You mean rbind+chroot and clone(CLONE_NS)? Yes, those are two > different mechanisms achieving very similar results. But what has > this to do with unprivileged mounts? The practical question is how do we limit what a user can mount and unmount. I would contend that at first glance stuffing a user in their own mount namespace is sufficient, on a system with utilities aware of the consequences of mount/…
creator: ebiederm
date: 2007-04-17T19:54:14-00:00

Re: Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
type: item
description: > > I've tried to make this unprivileged mount thing as simple as > > possible, and no simpler. If we can make it even simpler, all the > > better. > > We are certainly much more complex then the code in plan9 (just > read through it) so I think we have room for improvement. > > Just for reference what I saw in plan 9 was: > - No super user checks in it's mount, unmount, or namespace creation paths. > - A flag to deny new mounts but not new bind mounts (for administrative purposes > the comment said). > > Our differences from plan9. > - suid capable binaries. (SUID please go away). > - A history of programs assuming only root could call mount/unmount. I hate suid as well. _The_ motivation behind this patchset was to get rid of "fusermount", a suid mount helper for fuse. But I don't think suid is going away, and definitely not overnight. Also I don't think we want to require auditing userspace before enabling user mounts. If I understand correctly, your proposal is to get rid of MNT_USER and MNT_ALLOWUSERMNT and allow/deny unprivileged mounts and umounts based on a boolean sysctl flag and on a check if the target namespace is the initial namespace or not. And maybe add some extra checks which prevent ugliness from happening with suid programs. Is this correct? If so, how are we going to make sure this won't break existing userspace without doing a full audit of all suid programs in every distro that wants this feature? Also how are we going to prevent the user from creating millions of mounts, and using up all the kernel memory for vfsmounts? Miklos _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Miklos Szeredi
date: 2007-04-18T09:11:19-00:00

Re: Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
type: item
description: On Wed, 2007-04-18 at 11:11 +0200, Miklos Szeredi wrote: > > > I've tried to make this unprivileged mount thing as simple as > > > possible, and no simpler. If we can make it even simpler, all the > > > better. > > > > We are certainly much more complex then the code in plan9 (just > > read through it) so I think we have room for improvement. > > > > Just for reference what I saw in plan 9 was: > > - No super user checks in it's mount, unmount, or namespace creation paths. > > - A flag to deny new mounts but not new bind mounts (for administrative purposes > > the comment said). > > > > Our differences from plan9. > > - suid capable binaries. (SUID please go away). > > - A history of programs assuming only root could call mount/unmount. > > I hate suid as well. _The_ motivation behind this patchset was to get > rid of "fusermount", a suid mount helper for fuse. > > But I don't think suid is going away, and definitely not overnight. > Also I don't think we want to require auditing userspace before > enabling user mounts. > > If I understand correctly, your proposal is to get rid of MNT_USER and > MNT_ALLOWUSERMNT and allow/deny unprivileged mounts and umounts based > on a boolean sysctl flag and on a check if the target namespace is the > initial namespace or not. And maybe add some extra checks which > prevent ugliness from happening with suid programs. Is this correct? > > If so, how are we going to make sure this won't break existing > userspace without doing a full audit of all suid programs in every > distro that wants this feature? > > Also how are we going to prevent the user from creating millions of > mounts, and using up all the kernel memory for vfsmounts? Don't forget that almost all mount flags are per-superblock. How are you planning on dealing with the case that one user mounts a filesystem read-only, while another is trying to mount the same one read-write? Trond _______________________________________________ Containers mailing list Containers@lists.…
creator: Trond Myklebust
date: 2007-04-18T13:55:05-00:00

Re: Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
type: item
description: > > > > I've tried to make this unprivileged mount thing as simple as > > > > possible, and no simpler. If we can make it even simpler, all the > > > > better. > > > > > > We are certainly much more complex then the code in plan9 (just > > > read through it) so I think we have room for improvement. > > > > > > Just for reference what I saw in plan 9 was: > > > - No super user checks in it's mount, unmount, or namespace creation paths. > > > - A flag to deny new mounts but not new bind mounts (for administrative purposes > > > the comment said). > > > > > > Our differences from plan9. > > > - suid capable binaries. (SUID please go away). > > > - A history of programs assuming only root could call mount/unmount. > > > > I hate suid as well. _The_ motivation behind this patchset was to get > > rid of "fusermount", a suid mount helper for fuse. > > > > But I don't think suid is going away, and definitely not overnight. > > Also I don't think we want to require auditing userspace before > > enabling user mounts. > > > > If I understand correctly, your proposal is to get rid of MNT_USER and > > MNT_ALLOWUSERMNT and allow/deny unprivileged mounts and umounts based > > on a boolean sysctl flag and on a check if the target namespace is the > > initial namespace or not. And maybe add some extra checks which > > prevent ugliness from happening with suid programs. Is this correct? > > > > If so, how are we going to make sure this won't break existing > > userspace without doing a full audit of all suid programs in every > > distro that wants this feature? > > > > Also how are we going to prevent the user from creating millions of > > mounts, and using up all the kernel memory for vfsmounts? > > Don't forget that almost all mount flags are per-superblock. How are you > planning on dealing with the case that one user mounts a filesystem > read-only, while another is trying to mount the same one read-write? Yeah, I forgot, the per-mount read-only patches are not yet in. That doesn…
creator: Miklos Szeredi
date: 2007-04-18T14:03:23-00:00

Re: Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
type: item
description: On Wed, 2007-04-18 at 16:03 +0200, Miklos Szeredi wrote: > > Don't forget that almost all mount flags are per-superblock. How are you > > planning on dealing with the case that one user mounts a filesystem > > read-only, while another is trying to mount the same one read-write? > > Yeah, I forgot, the per-mount read-only patches are not yet in. > > That doesn't really change my agrument though. _If_ the flag is per > mount, then it makes sense to be able to change it on a master and not > on a slave. If mount flags are propagated, this is not possible. Read-only isn't the only issue. On something like NFS, there are flags to set the security flavour, turn on/off encryption etc. If I mount your home directory using no encryption in my namespace, for instance, then neither you nor the administrator will be able to turn it on afterwards in yours without first unmounting it from mine so that the superblock is destroyed. Cheers Trond _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Trond Myklebust
date: 2007-04-18T14:26:29-00:00

Re: Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
type: item
description: On Wed, Apr 18, 2007 at 10:26:29AM -0400, Trond Myklebust wrote: > > That doesn't really change my agrument though. _If_ the flag is per > > mount, then it makes sense to be able to change it on a master and not > > on a slave. If mount flags are propagated, this is not possible. > > Read-only isn't the only issue. On something like NFS, there are flags > to set the security flavour, turn on/off encryption etc. > > If I mount your home directory using no encryption in my namespace, for > instance, then neither you nor the administrator will be able to turn it > on afterwards in yours without first unmounting it from mine so that the > superblock is destroyed. I suspect the right answer here is to make nfs mount handling smarter. The way mounting works the filesystem is allowed to choose whether it can re-used a superblock or needs a new one. In the NFS case we probably want to allow multiple superblocks for the same export if important paramaters like the security model mismatch. This is however only the technical part of the answer. There's a more important one, and that's the user experience - we need a much better way to document which flags are per-superblock and which are per-mount. Due to this and some other issues we'll probably need a new mount API in some time. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Christoph Hellwig
date: 2007-04-18T15:01:10-00:00

Re: Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
type: item
description: > > > Don't forget that almost all mount flags are per-superblock. How are you > > > planning on dealing with the case that one user mounts a filesystem > > > read-only, while another is trying to mount the same one read-write? > > > > Yeah, I forgot, the per-mount read-only patches are not yet in. > > > > That doesn't really change my agrument though. _If_ the flag is per > > mount, then it makes sense to be able to change it on a master and not > > on a slave. If mount flags are propagated, this is not possible. > > Read-only isn't the only issue. On something like NFS, there are flags > to set the security flavour, turn on/off encryption etc. > > If I mount your home directory using no encryption in my namespace, for > instance, then neither you nor the administrator will be able to turn it > on afterwards in yours without first unmounting it from mine so that the > superblock is destroyed. OK, that's interesting, but I fail to grasp the relevance of this to unprivileged mounts. Or are you thinking of unprivileged NFS mounts? Well, think again, because that involves _much_ more than it seems at first glance. Miklos _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Miklos Szeredi
date: 2007-04-18T15:06:33-00:00

Re: Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
type: item
description: Miklos Szeredi <miklos@szeredi.hu> writes: >> > I've tried to make this unprivileged mount thing as simple as >> > possible, and no simpler. If we can make it even simpler, all the >> > better. >> >> We are certainly much more complex then the code in plan9 (just >> read through it) so I think we have room for improvement. >> >> Just for reference what I saw in plan 9 was: >> - No super user checks in it's mount, unmount, or namespace creation paths. >> - A flag to deny new mounts but not new bind mounts (for administrative > purposes >> the comment said). >> >> Our differences from plan9. >> - suid capable binaries. (SUID please go away). >> - A history of programs assuming only root could call mount/unmount. > > I hate suid as well. _The_ motivation behind this patchset was to get > rid of "fusermount", a suid mount helper for fuse. > > But I don't think suid is going away, and definitely not overnight. Agreed, unless it just happens that killing is equally as hard as doing non-privileged mounts. Which I really don't think will be the case. suid executables can always be replaced by a non-privileged part that connect to a daemon on localhost. > Also I don't think we want to require auditing userspace before > enabling user mounts. Given the complexity of the code to avoids audits adds, and especially the uncertainty of how all of the pieces add up together I really think we do need to audit user space (but only in a limited way). This is a paradigm shift in how mounts are managed and to get the full benefit of it we need to be prepared to deal with the paradigm shift. Essentially what the audit must ensure is that (a) non-root users are always run in a non-default namespace so mounts and unmounts they generate will not have global effect. (b) If we setup something like the proposed /share that administrative tools know how to treat it properly. That is not an especially hard audit of user space and it noticeably reduces the complexity of what we must implement. > …
creator: ebiederm
date: 2007-04-18T17:14:57-00:00

Re: Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
type: item
description: > >> > I've tried to make this unprivileged mount thing as simple as > >> > possible, and no simpler. If we can make it even simpler, all the > >> > better. > >> > >> We are certainly much more complex then the code in plan9 (just > >> read through it) so I think we have room for improvement. > >> > >> Just for reference what I saw in plan 9 was: > >> - No super user checks in it's mount, unmount, or namespace creation paths. > >> - A flag to deny new mounts but not new bind mounts (for administrative > > purposes > >> the comment said). > >> > >> Our differences from plan9. > >> - suid capable binaries. (SUID please go away). > >> - A history of programs assuming only root could call mount/unmount. > > > > I hate suid as well. _The_ motivation behind this patchset was to get > > rid of "fusermount", a suid mount helper for fuse. > > > > But I don't think suid is going away, and definitely not overnight. > > Agreed, unless it just happens that killing is equally as hard as > doing non-privileged mounts. Which I really don't think will be > the case. suid executables can always be replaced by a non-privileged > part that connect to a daemon on localhost. > > > Also I don't think we want to require auditing userspace before > > enabling user mounts. > > Given the complexity of the code to avoids audits adds, and especially > the uncertainty of how all of the pieces add up together I really > think we do need to audit user space (but only in a limited way). > > This is a paradigm shift in how mounts are managed and to get > the full benefit of it we need to be prepared to deal with the > paradigm shift. > > Essentially what the audit must ensure is that > (a) non-root users are always run in a non-default namespace so > mounts and unmounts they generate will not have global effect. But unprivileged proceses are not only created through login. What happens, when some process does setuid(NONZERO). With your proposal it now gained the privilege of mounting in the initial …
creator: Miklos Szeredi
date: 2007-04-18T18:05:34-00:00

Re: Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
type: item
description: On Wed, 2007-04-18 at 16:01 +0100, Christoph Hellwig wrote: > I suspect the right answer here is to make nfs mount handling smarter. > The way mounting works the filesystem is allowed to choose whether it > can re-used a superblock or needs a new one. In the NFS case we probably > want to allow multiple superblocks for the same export if important > paramaters like the security model mismatch. It might also be another application for layering. If I were able to share enough of the inode and dentry information between superblocks, then all sorts of interesting possibilities arise... Cheers Trond _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Trond Myklebust
date: 2007-04-18T19:00:47-00:00

Re: Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
type: item
description: > Checking the permissions on the mountpoint to allow unmounting is > > - rather inelegant: user can't see those permissions, can only > determine if umount is allowed by trial and error > > - may be a security hole, e.g.: > > sysadmin: > > mkdir -m 777 /mnt/disk > mount /dev/hda2 /mnt/disk > > Of course the user doesn't have the right to delete the contents of > the mount, yet the permissions on the mountpoint would imply that s/he > has permission to umount the disk. It is becoming increasingly apparent, that mount/umount permission based on file permissions is inherently broken: 1) there are user-writable files under /proc/$PID/, which definitely shouldn't be allowed to be overmounted 2) if user mounts an fs read-only, then wants to create a submount of this, it will fail with the current patchset Solving 2) should be trivial: submounting a mount owned by the user should be always allowed regardless of the file permissions. Maybe this could be generaized to say, that a mount can be submounted by an unprivileged user IFF parent mount is owned by said user. This would get rid of some of the complications in the current patchset, namely the functionality of MNT_ALLOWUSERMNT and MNT_USER flags would be merged, and the permission checking would be removed. For example on login, the user could get a private namespace set up some that the home directory is owned by the user, and hence can be freely submounted: clone(CLONE_NEWNS) mount --bind /home/$USER /home/$USER mount --remount -ouser=$USER /home/$USER This is of course more limiting than allowing mounts based on file permissions, but it's also a lot cleaner. Hmm? Miklos _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Miklos Szeredi
date: 2007-04-19T09:02:10-00:00