public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serge@hallyn.com>
To: Eric Paris <eparis@redhat.com>
Cc: linux-kernel@vger.kernel.org,
	containers@lists.linux-foundation.org, oleg@redhat.com,
	richard@nod.at, akpm@linux-foundation.org, ebiederm@xmission.com,
	dhowells@redhat.com,
	"Serge E. Hallyn" <serge.hallyn@canonical.com>
Subject: Re: [PATCH 6/6] protect cap_netlink_recv from user namespaces
Date: Tue, 8 Nov 2011 03:29:02 +0000	[thread overview]
Message-ID: <20111108032902.GA29433@hallyn.com> (raw)
In-Reply-To: <1320694510.10093.23.camel@localhost>

Quoting Eric Paris (eparis@redhat.com):
> On Fri, 2011-11-04 at 22:24 +0000, Serge Hallyn wrote:
> > From: Serge E. Hallyn <serge.hallyn@canonical.com>
> > 
> > cap_netlink_recv() was granting privilege if a capability is in
> > current_cap(), regardless of the user namespace.  Fix that by
> > targeting the capability check against the user namespace which
> > owns the skb.
> > 
> > Caller passes the user ns down because sock_net is static inline defined in
> > net/sock.h, which we'd rather not #include at the cap_netlink_recv function.
> 
> This is wrong at least in relation to audit.

You may well be right, but before I proceed, I want to make sure that
you do see the current code is even more wrong?  But I was (as with the other
patch I reverted) probably overzealous and should have switched this a
different way (see bottom).

Regarding audit:  if I create a new network namespace, I can't open a
netlink socket to talk to the kernel.  At least,

	unshare -n /bin/bash
	# strace -f auditctl -l

shows -ECONNREFUSED from the sendto.  So I'm really not sure that the
kernel/audit.c patch is wrong.  (I want to make sure it's understood,
below, that I'm proposing tightening down the checks because that's more
in keeping with the purpose of this patchset, not because I agree the
checks are or will be, in the end, wrong)

>   I don't know the other
> code well enough to know if I think it's ok there.  Lets say I have
> (CAP_SYS_ADMIN | CAP_SETUID | CAP_SETGID) and I create a new task with
> CLONE_NEWNAME.

(just to be sure, do you mean CLONE_NEWUSER?)

>   This task then immediately does the needful to remove
> all audit rules (which supposedly requires CAP_AUDIT_CONTROL).  That's
> going to succeed because the task is init in it's namespace, aka:
> 
>         /* The creator of the user namespace has all caps. */
>         if (targ_ns != &init_user_ns && targ_ns->creator == cred->user)
>                 return 0;

That will only happen if the current user created the target user_ns.
So if task p1 created task p2 through clone(CLONE_NEWUSER), then p1 would
pass this on access check to p2's user_ns, but p2 would not.

But that really isn't related to the issue you raise.

> But it just screwed with a global resource.  aka audit.  I don't know
> the meaning of these others, but it seems to me probably most or all of
> them should be against the init_user_ns, not the namespace the skb came
> from....
> 
> What am I missing?

I'm not sure, depends on how much we're misunderstanding each other :)

But, regardless, your point is valid in that I'm not tightening down as
much as I could.  So how about I don't change the security_netlink_recv()
and callers yet, and instead I change cap_netlink_recv() to do:

	if (!IN_ROOT_USER_NS && !cap_raised(current_cap(), cap))

?

thanks,
-serge

  reply	other threads:[~2011-11-08  3:28 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-04 22:24 user namespaces: fix some uid/privilege leaks Serge Hallyn
2011-11-04 22:24 ` [PATCH 1/6] user namespace: make signal.c respect user namespaces (v4) Serge Hallyn
2011-11-09  0:22   ` Andrew Morton
2011-11-09 14:18     ` Serge E. Hallyn
2011-11-10  1:41       ` Matt Helsley
2011-11-10 14:27         ` Serge E. Hallyn
2011-11-04 22:24 ` [PATCH 2/6] User namespace: don't allow sysctl in non-init user ns (v2) Serge Hallyn
2011-11-04 22:24 ` [PATCH 3/6] user namespace: clamp down users of cap_raised Serge Hallyn
2011-11-06  1:14   ` Andrew G. Morgan
2011-11-04 22:24 ` [PATCH 4/6] Add Documentation/namespaces/user_namespace.txt (v3) Serge Hallyn
2011-11-04 22:24 ` [PATCH 5/6] user namespace: make each net (net_ns) belong to a user_ns Serge Hallyn
2011-11-04 22:24 ` [PATCH 6/6] protect cap_netlink_recv from user namespaces Serge Hallyn
2011-11-07 19:35   ` Eric Paris
2011-11-08  3:29     ` Serge E. Hallyn [this message]
2011-11-09 14:19       ` Eric Paris
2011-11-09 14:44         ` Serge E. Hallyn
2011-11-19  9:10         ` Eric W. Biederman
2011-11-19 23:25           ` Serge E. Hallyn
2011-11-11  4:13 ` user namespaces: fix some uid/privilege leaks Serge E. Hallyn

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=20111108032902.GA29433@hallyn.com \
    --to=serge@hallyn.com \
    --cc=akpm@linux-foundation.org \
    --cc=containers@lists.linux-foundation.org \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=eparis@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=richard@nod.at \
    --cc=serge.hallyn@canonical.com \
    /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