"Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx> writes: > [Dropping Eric into CC, in case he has time to comment.] > > Hi Tycho, > > On Wed, 31 Oct 2018 at 20:18, Tycho Kirchner <tychokirchner@xxxxxxx> wrote: >> >> Am 31.10.18 um 08:48 schrieb Michael Kerrisk (man-pages): >> > Hello Tycho, >> > >> > On Thu, 25 Oct 2018 at 14:51, Tycho Kirchner <tychokirchner@xxxxxxx> wrote: >> >> >> >> Update the mount_namespaces(7) with a mention that unsharing the >> >> mountspace require the CAP_SYS_ADMIN-capability. >> > >> > But this is already fairly clearly stated in the unshare(2) page (and >> > is also mentioned in namespaces(7)). It seems to me unnecessary to >> > repeat the info in mount_namespaces(7), but then I do not read this >> > page as a new user. Tell me, did you miss the info in unshare(2), or >> > do you feel that nevertheless the info should be repeated? >> > >> >> If possible, please >> >> also add a justification because I know of several people who would like >> >> to understand that. >> > >> > I've tried to capture this by adding a few words to the namespaces(7) page; >> > >> > Creation of new namespaces using clone(2) and unshare(2) in most >> > cases requires the CAP_SYS_ADMIN capability, **since, in the new >> > namespace, the creator will have the power to change global >> > resources that are visible to other processes that are subse‐ >> > quently created in, or join the namespace**. >> > >> >> (In fact I'm about to write a setuid-program which allows unsharing the >> >> mountspace for everyone and was wondering, if that is insecure in any >> >> way? What is the rationale behind disallowing unsharing the mountspace >> >> for regular users? Note that I know that doing so is possible by also >> >> unsharing the usernamespace, but this introduces other limitations [e.g. >> >> setuid-programs cannot be called from there]). >> > >> > A while back, I added some text to the capabilities(7) manual page >> > (http://man7.org/linux/man-pages/man7/capabilities.7.html) that may >> > help you better understand what's going on here. See the subsections >> > "File capability mask versioning" and "Namespaced file capabilities". >> > >> >> Thank you very much, also for the valuable work you have done so far. >> > >> > You're welcome. Unfortunately, my available time is quite limited these days... >> > >> > Cheers, >> > >> > Michael >> > >> >> Hello Michael, >> thanks for your answer. >> Repeating that unsharing the mount namespace requires CAP_SYS_ADMIN >> within mount_namespaces(7) makes sense with regard to an explanation, >> *why* in particular unsharing the mount-namespace needs this capability. >> >> > Creation of new namespaces using clone(2) and unshare(2) in most >> > cases requires the CAP_SYS_ADMIN capability, **since, in the new >> > namespace, the creator will have the power to change global >> > resources that are visible to other processes that are subse‐ >> > quently created in, or join the namespace** >> >> I don't think this is true with reference to mount namespaces. Imagine >> it was allowed to *merely* unshare the mount namespace for a regular >> user *without* unsharing the user namespace . As I understand it, the >> security relevant bits (e.g. mount propagation into the parent >> mountspace) *only* apply if a respective mount is actually performed. >> However, this is not possible, since the user does *not* have the power >> to do so. > Yes, but that's the point isn't it? If you could unshare a mount > namespace as an unprivileged user, you still wouldn't be able to > create mount points, so it wouldn't be very useful. But, see my > furtehr comments below. If you don't have user namespaces to protect you from using your mount namespace on setuid applications that gain privilege when exec'd you have the potential to create what is in effect a replay attack against those exec'd setuid applications. Which means that even a simple unshare is security relevant. >> > A while back, I added some text to the capabilities(7) manual page >> > (http://man7.org/linux/man-pages/man7/capabilities.7.html) that may >> > help you better understand what's going on here. See the subsections >> > "File capability mask versioning" and "Namespaced file capabilities". >> >> These subsections seem to refer to user namespaces - could you please >> elaborate how mount-namespaces are concerned? > > Sorry -- I meant to point you to that text with regard to your > comments about how set-UID programs work in user namespaces. It was > not relevant to mount namespaces. > >> It seems to me that unsharing the mountspace is a safe thing and the >> dangerous stuff begins when actually creating the mount-points, which >> however is *not* possible without root-privileges/setuid-programs. >> Maybe the implementers of the unshare syscall had too much the >> mount-operations in mind and thought it would not make sense to allow >> anyone creating a new mount namespace because for performing a mount >> root-privileges were required anyway? >> >> Do you share my thoughts? > > Okay -- maybe I see your point now. To summarize: > > 1. Set-UID-root programs can make mount points (because they have the > CAP_SYS_ADMIN capability). > 2. Imagine an alternative world where an unprivileged user could > unshare the mount NS. > 3. In that alternative world, the user would not be able to create > mount points, unless they ran a suitable set-UID-root program that > allowed them to do so (or switched to root using sudo) . (And that > same program could be used in any case by the unprivileged user from > the *initial* mount NS.) > > I suspect that the reason this scenario isn't allowed is: > 1) It's an unlikely use case. I mean, in step 3 you'll need to be > running some privileged program anyway, so why not just require > privilege to create the new mount namespace? > 2) As kernel developers, let's be conservative and allow only the use > cases we know are useful and we believe are safe. > > But, that's just my estimation. I think that is how we go to where we are but see above I do see attack possibilities on setuid root applications even with just creating a mount namespace. > Regarding your intent to create a set-UID-root program that allows any > user to unshare the mount NS, I'm not sure of the security > implications, but I would feel a little nervous about this. Note also > that there is work in progress to allow mounts if filesystems by > unprivileged users in an unshared user+mount namespace set-up. My thoughts: a) I do forsee attacks b) Anyone can create a user namespace and then a mount namespace so I don't see the point of a set-UID-root program. c) The work to support mounting a filesystem in your own mount namespace owned by your own user namespace is essentially complete at this point. Michael do we need to update the man pages somewhere to document that you can now mount fuse filesystems in any mount namespace? Eric
