All of lore.kernel.org
 help / color / mirror / Atom feed
From: "U.Mutlu" <for-gmane@mutluit.com>
To: util-linux@vger.kernel.org
Subject: Re: unshare -m should not be a privileged option
Date: Tue, 17 Nov 2015 07:54:57 +0100	[thread overview]
Message-ID: <n2ej02$10r$1@ger.gmane.org> (raw)
In-Reply-To: <20151116041931.GC5949@vapier.lan>

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.



      parent reply	other threads:[~2015-11-17  6:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-16  2:26 unshare -m should not be a privileged option U.Mutlu
2015-11-16  4:19 ` Mike Frysinger
2015-11-16 15:43   ` user namespaces: user mapping U.Mutlu
2015-11-16 23:41     ` U.Mutlu
2015-11-17  4:32       ` Mike Frysinger
2015-11-17  5:25         ` U.Mutlu
2015-11-17 20:58           ` Mike Frysinger
2015-11-17  6:54   ` U.Mutlu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='n2ej02$10r$1@ger.gmane.org' \
    --to=for-gmane@mutluit.com \
    --cc=util-linux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.