Am 02.11.18 um 12:32 schrieb Eric W. Biederman:
"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
Hi Michael, Eric
and thanks for your answers.
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.
Yes, as I said, one of the reasons I would like to avoid user NS is,
because I want to allow the user, to call setuid-programs even after
unsharing the mountspace. But I don't understand how a <replay attack>
would be possible - the user has not more privileges after unshare NEWNS
than before - only the mount ids changed. Even if a new user NS was
created after unsharing the mount NS nothing harmful should happen,
because the usual restrictions on user NS apply regardless of the new
mount NS. The entering of the original mountspace from within the new
user NS must of course remain prohibited.
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
Actually to me it would be very useful (= . I could continually unshare
the mountspace from within *the same unprivileged* process setting up
the mounts in a safe manner from another setuid-program.
So to me the question is primarily whether it is safe (and if it is, why
not allow the feature in the Kernel).
Best regards
Tycho
