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;
> }
prev 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