Linux Container Development
 help / color / mirror / Atom feed
From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
To: Huang Qiang <h.huangqiang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Subject: Re: [PATCH] user_ns: Use nsown_capable instead of capable in net_ctl_permissions
Date: Wed, 25 Jul 2012 04:32:09 -0700	[thread overview]
Message-ID: <87eho084au.fsf@xmission.com> (raw)
In-Reply-To: <500E815D.4070605-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> (Huang Qiang's message of "Tue, 24 Jul 2012 19:05:01 +0800")


To expand a bit on Serge's reply.

Huang Qiang <h.huangqiang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> writes:

> From: Zhao Hongjiang <zhaohongjiang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>
> HI:
> When I use an unprivileged user exec the following command:
> # nsexec -cUn /bin/bash
> to create a container with new user_ns and net_ns.
>
> Then I exec "echo 4096 4096 4096 > /proc/sys/net/ipv4/tcp_mem",
> the result is Permission Denied which we hope it should be allowed.
>
> It is because of capable(CAP_NET_ADMIN).
>
> Even my unprivileged user have the CAP_NET_ADMIN in the new user_ns and the
> tcp_mem is belong to the new net_ns, the capable(CAP_NET_ADMIN) checking is
> that this must in the init_user_ns, so the result is the network administrator
> can't have the same access as root.
>
> Use nsown_capable(...) the problem is solved.
>
> PS: I changed lxc almostly like what serge done, then use an unprivileged user
> to start a container, several Permission Denied occur(such as mount), all this
> is caused by capabale(...), when i use nsown_capable(...) the container is
> running like everything is ok.

> Is this capabale() methed is obsolete? If so, i'll send a new patch to solve
> all this problems.

No capable is not really obsolete.

Your patch is a bit scary, and this is definitely an area we
need to do some work in.

There are a couple of pieces to this.  If you raise tcp_mem you can
allow yourself to take up unlimited amounts of kernel memory.  We
should not allow that for an unprivilged user, and unprivilged users
are allowed to create a user namespaces and then network namespaces.

The replacement should be ns_capable not nsown_capable.  We don't
want to allow any process that happens to have CAP_NET_ADMIN in their
user namespace to have root privileges over any syctl file they can
get a file descriptor to.

cap_capable exists so that we can take our time and audit these things.
Potentially we could change all cap_capable to
"ns_capable(&init_user_ns, ...)" but that doesn't buy us much in the short
term.

So while I think your patch is in the right ballpark, I think a correct
version of allowing an unprivileged user to raise tcp_mem is something
we need to do a bit more carefully.

Eric


> Signed-off-by: Zhao Hongjiang<zhaohongjiang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Huang Qiang <h.huangqiang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> ---
>  net/sysctl_net.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/sysctl_net.c b/net/sysctl_net.c
> index c3e65ae..ee31777 100644
> --- a/net/sysctl_net.c
> +++ b/net/sysctl_net.c
> @@ -47,7 +47,7 @@ static int net_ctl_permissions(struct ctl_table_root *root,
>  			       struct ctl_table *table)
>  {
>  	/* Allow network administrator to have same access as root. */
> -	if (capable(CAP_NET_ADMIN)) {
> +	if (nsown_capable(CAP_NET_ADMIN)) {
>  		int mode = (table->mode >> 6) & 7;
>  		return (mode << 6) | (mode << 3) | mode;
>  	}

      parent reply	other threads:[~2012-07-25 11:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-24 11:05 [PATCH] user_ns: Use nsown_capable instead of capable in net_ctl_permissions Huang Qiang
     [not found] ` <500E815D.4070605-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2012-07-24 14:20   ` Serge Hallyn
2012-07-25 11:32   ` Eric W. Biederman [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=87eho084au.fsf@xmission.com \
    --to=ebiederm-as9lmozglivwk0htik3j/w@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=h.huangqiang-hv44wF8Li93QT0dZR+AlfA@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox