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.
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?
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?
Best regards
Tycho
