From: ebiederm@xmission.com (Eric W. Biederman)
To: Eric Paris <eparis@redhat.com>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
richard@nod.at, containers@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, oleg@redhat.com,
dhowells@redhat.com, akpm@linux-foundation.org
Subject: Re: [PATCH 6/6] protect cap_netlink_recv from user namespaces
Date: Sat, 19 Nov 2011 01:10:29 -0800 [thread overview]
Message-ID: <m11ut41nqy.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <1320848342.10093.57.camel@localhost> (Eric Paris's message of "Wed, 09 Nov 2011 09:19:02 -0500")
Eric Paris <eparis@redhat.com> writes:
> On Tue, 2011-11-08 at 03:29 +0000, Serge E. Hallyn wrote:
>> Quoting Eric Paris (eparis@redhat.com):
>
>> 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))
>
> Actually better thought. Remove the LSM hook altogether and just use
> capable() in the callers. This hook, being used this way, was
> introduced in c7bdb545 back when we took the effective perms from the
> skb. We don't use the skb any more since netlink is synchronous. This
> is functionally equivalent except the capabilities code checks against
> the init_user_ns (something we want) and it will now set PF_PRIV (which
> also seems like a good thing) Something like:
>
> security: remove the security_netlink_recv hook as it is equivalent to capable()
>
> Once upon a time netlink was not sync and we had to get the effective
> capabilities from the skb that was being received. Today we instead get
> the capabilities from the current task. This has rendered the entire
> purpose of the hook moot as it is now functionally equivalent to the
> capable() call.
>
> Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Darn. I missed this one went it went past the first time. Let's do
this.
As Serge pointed out checking against the user namespace of the network
namespace happens to be safe because the subsystems that are brittle
really have problems don't support multiple network namespaces.
Still I like the idea of erring on the conservative side here and
making everything safe. We can open relax the restrictions later
by using ns_capable. I want to get to a point where it is safe
for an unprivileged user to create their own user namespace,
and most of that is just getting the capable calls correct.
Eric
next prev parent reply other threads:[~2011-11-19 9:09 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
2011-11-09 14:19 ` Eric Paris
2011-11-09 14:44 ` Serge E. Hallyn
2011-11-19 9:10 ` Eric W. Biederman [this message]
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=m11ut41nqy.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=containers@lists.linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=eparis@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=richard@nod.at \
--cc=serge@hallyn.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