unshare -m should not be a privileged option

unshare -m should not be a privileged option

[U.Mutlu]

I'm proposing that "unshare -m" should not be a privileged option,
because in practice it is IMO used like this:

unshare -m /bin/bash
now user can do his mounts (mostly via sudo)

The user should need the root permission (or CAP_ADMIN or whatever
caps it needs) only for the mount and unmount cmds, but not for "unshare -m".

Therefore the -m option (and maybe even most of the other options) of unshare
should be made to work for users, without needing root permission.

Maybe even better would be to define the users in a new conf file 
/etc/unshare.conf or so.

The other solution via user namespace is IMHO overkill and in my case 
impractical and irritating because user gets a root-prompt (#)
eventhough it is only inside the user namespace.

I like "unshare -m", but it should work also for unprivileged users without 
needing sudo.

As said in previous postings of mine: "chmod u+s unshare" does what I need,
but I don't know if that solution will continue working in newer versions.

...just my .02 cents from the field as admin and user

Re: unshare -m should not be a privileged option

[Mike Frysinger]

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

On 16 Nov 2015 03:26, U.Mutlu wrote:
> I'm proposing that "unshare -m" should not be a privileged option,

what you're asking for is not coming from util-linux.  unshare is merely an
interface to the unshare() syscall.  if you dislike the security semantics
there, you can post to the namespace mailing list:
https://lists.linuxfoundation.org/mailman/listinfo/containers

> Therefore the -m option (and maybe even most of the other options) of unshare
> should be made to work for users, without needing root permission.

they do already -- with user namespaces.  if you give people the ability to
mount anything in the existing mount namespace, you open up attacks:
- create an ext2 fs as the user with some setuid programs
- create a new mount namespace
- mount that image
- instant root

> The other solution via user namespace is IMHO overkill and in my case 
> impractical and irritating because user gets a root-prompt (#)
> eventhough it is only inside the user namespace.

so remap it to your own user instead of to root

> As said in previous postings of mine: "chmod u+s unshare" does what I need,

i would like shell access to your systems please.  free root is fun.
-mike

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

user namespaces: user mapping

[U.Mutlu]

Mike Frysinger wrote on 11/16/2015 05:19 AM:
> On 16 Nov 2015 03:26, U.Mutlu wrote:
>
>> The other solution via user namespace is IMHO overkill and in my case
>> impractical and irritating because user gets a root-prompt (#)
>> eventhough it is only inside the user namespace.
>
> so remap it to your own user instead of to root

Sorry, I forgot the dangers of mounting into existing mount namespace.
Yes, user namespace seems to be the way to go, so I tried the sample from
man user_namespaces:

$ ./userns_child_exec -v -p -m -U -z bash
./userns_child_exec: PID of child created by clone() is 2950
ERROR: write /proc/2950/gid_map: Operation not permitted
About to exec bash

Am I on the right track with the above method for user remapping?

It's maybe that under Debian another sysctl-setting is needed
for this to work, I'll need to do some research on the net.
If someone here knows the solution let me know pls.

Re: user namespaces: user mapping

[U.Mutlu]

U.Mutlu wrote on 11/16/2015 04:43 PM:
> Mike Frysinger wrote on 11/16/2015 05:19 AM:
>> On 16 Nov 2015 03:26, U.Mutlu wrote:
>>
>>> The other solution via user namespace is IMHO overkill and in my case
>>> impractical and irritating because user gets a root-prompt (#)
>>> eventhough it is only inside the user namespace.
>>
>> so remap it to your own user instead of to root
>
> Sorry, I forgot the dangers of mounting into existing mount namespace.
> Yes, user namespace seems to be the way to go, so I tried the sample from
> man user_namespaces:
>
> $ ./userns_child_exec -v -p -m -U -z bash
> ./userns_child_exec: PID of child created by clone() is 2950
> ERROR: write /proc/2950/gid_map: Operation not permitted
> About to exec bash
>
> Am I on the right track with the above method for user remapping?
>
> It's maybe that under Debian another sysctl-setting is needed
> for this to work, I'll need to do some research on the net.
> If someone here knows the solution let me know pls.

I did some research on the net, and the findings are:
  - user namespaces have their own security holes
  - a workaround exists, but then a new problem happens: loop devices cannot 
be accessed

Here's the output of a modified (fixed) version of the above pgm,
but mount still not working, even with root-prompt inside the namespace:

$ ./userns_child_exec -v -m -U -z bash
uid=1003 gid=1006 pid=7728
./userns_child_exec: PID of child created by clone() is 7729
uid=1003 gid=1006 pid=7729
map_file=/proc/7729/setgroups map_val=deny
map_file=/proc/7729/uid_map map_val=0 1003 1
map_file=/proc/7729/gid_map map_val=0 1006 1
About to exec bash

# mount -o loop ../mount-test/theFile.img mnt
mount: /home/user/tmp/test/mount-test/theFile.img: failed to setup loop 
device: Permission denied

# ls -l /dev/loop*
brw-rw---- 1 nobody nogroup  7,   0 Nov 16 20:01 /dev/loop0
brw-rw---- 1 nobody nogroup  7,   1 Nov 16 20:14 /dev/loop1
brw-rw---- 1 nobody nogroup  7,   2 Nov 16 15:29 /dev/loop2
brw-rw---- 1 nobody nogroup  7,   3 Nov 16 15:29 /dev/loop3
brw-rw---- 1 nobody nogroup  7,   4 Nov 16 15:29 /dev/loop4
brw-rw---- 1 nobody nogroup  7,   5 Nov 16 15:29 /dev/loop5
brw-rw---- 1 nobody nogroup  7,   6 Nov 16 15:29 /dev/loop6
brw-rw---- 1 nobody nogroup  7,   7 Nov 16 15:29 /dev/loop7
crw-rw---- 1 nobody nogroup 10, 237 Nov 16 15:29 /dev/loop-control

Does the user need to create his own loop device(s)?

Hmm. it looks like there is (currently?) a big mess with user namespaces:
https://code.google.com/p/chromium/issues/detail?id=457362

Re: user namespaces: user mapping

[Mike Frysinger]

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

On 17 Nov 2015 00:41, U.Mutlu wrote:
> I did some research on the net, and the findings are:
>   - user namespaces have their own security holes

there are no known security issues.  like all new code, there were some edge
cases in the original implementation, but they've been fixed since.  the only
thing left is that people don't like the new attack surface and inherently
distrust it.  but that's not the same thing as there being known security holes.

>   - a workaround exists, but then a new problem happens: loop devices cannot 
> be accessed

loop devices are merely files which are owned by the root user.  not being able
to open files owned by the "real" root is to be expected.

> Does the user need to create his own loop device(s)?

you need to have the system/root chown them as the user before doing anything
else.  sucks, but that's currently how it works.  would be nice if someone 
looked into making it more accessible to users.  maybe others on this list are
aware of ongoing work.

> Hmm. it looks like there is (currently?) a big mess with user namespaces:
> https://code.google.com/p/chromium/issues/detail?id=457362

no, no there is not
-mike

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

Re: user namespaces: user mapping

[U.Mutlu]

Mike Frysinger wrote on 11/17/2015 05:32 AM:
> On 17 Nov 2015 00:41, U.Mutlu wrote:
>> I did some research on the net, and the findings are:
>>    - user namespaces have their own security holes
>
> there are no known security issues.  like all new code, there were some edge
> cases in the original implementation, but they've been fixed since.  the only
> thing left is that people don't like the new attack surface and inherently
> distrust it.  but that's not the same thing as there being known security holes.

see below

>>    - a workaround exists, but then a new problem happens: loop devices cannot
>> be accessed
>
> loop devices are merely files which are owned by the root user.  not being able
> to open files owned by the "real" root is to be expected.
>
>> Does the user need to create his own loop device(s)?
>
> you need to have the system/root chown them as the user before doing anything
> else.  sucks, but that's currently how it works.

Come on, what about the other users and the system itself, as they need them 
too...

>  would be nice if someone
> looked into making it more accessible to users.  maybe others on this list are
> aware of ongoing work.
>
>> Hmm. it looks like there is (currently?) a big mess with user namespaces:
>> https://code.google.com/p/chromium/issues/detail?id=457362
>
> no, no there is not

This is an excerpt from a recent posting (Oct-17) in the containers newsgroup 
you posted the link here ( 
http://lists.linuxfoundation.org/pipermail/containers/2015-October/036333.html 
), cite:

|>>> Linux 3.8 saw the introduction of unpriviledged user namespaces,
|>>> allowing unpriviledged users (without CAP_SYS_ADMIN) to be a "fake" root
|>>> inside a separate user namespace. Before that, any namespace creation
|>>> required CAP_SYS_ADMIN (or, in practice, the user had to be root).
|>>> Unfortunately, there have been some security-relevant bugs in the
|>>> meantime. Because of the fairly complex nature of user namespaces, it is
|>>> reasonable to say that future vulnerabilties can not be excluded. Some
|>>> distributions even wholly disable user namespaces because of this.

user namespaces is not mature yet.

Re: user namespaces: user mapping

[Mike Frysinger]

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

this really isn't the place for logical fallacies.  it is impossible to prove
any code is entirely bug free (let's ignore the theoretical proof based systems
as they're entirely irrelevant to this discussion).  if you have any actual bugs
to report, then do so.  otherwise, you're wasting everyone's time.

i think we've all been pretty clear that making unshare, as-is, setuid is
completely wrong and, frankly, stupid.  it's trivial to leverage privilege
escalation after that point.

as for enhancing unshare to be aware that it's setuid and thus drop root back
once it's done making the unshare calls, i don't see the point.  user namespaces
work already and don't require setuid and are widely available.  if you don't
like userns, that's your choice, but not our problem.
-mike

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

Re: unshare -m should not be a privileged option

[U.Mutlu]

Mike Frysinger wrote on 11/16/2015 05:19 AM:
> On 16 Nov 2015 03:26, U.Mutlu wrote:
>> I'm proposing that "unshare -m" should not be a privileged option,
>
> what you're asking for is not coming from util-linux.  unshare is merely an
> interface to the unshare() syscall.  if you dislike the security semantics
> there, you can post to the namespace mailing list:
> https://lists.linuxfoundation.org/mailman/listinfo/containers
>
>> Therefore the -m option (and maybe even most of the other options) of unshare
>> should be made to work for users, without needing root permission.
>
> they do already -- with user namespaces.  if you give people the ability to
> mount anything in the existing mount namespace, you open up attacks:
> - create an ext2 fs as the user with some setuid programs
> - create a new mount namespace
> - mount that image
> - instant root

I think there is a 'misunderstanding': it happens earlier, ie. when doing
"unshare -m bash" then you already become root in the new shell.
It has nothing to do with ext2 or the mount.

As I already said: solution to this problem is:
chmod u+s unshare
and starting the unshare cmd unpriviledged (ie. as user) and directly (ie. not 
via sudo).

But the bind-mount danger (vuln) still remains.