On Mon, Aug 10, 2015 at 09:11:08AM +0300, Haggai Eran wrote:
> On 07/08/2015 00:08, ira.we...@intel.com wrote:
> > @@ -754,6 +764,12 @@ static int ib_nl_handle_resolve_resp(struct sk_buff
> > *skb,
> > int found = 0;
> > int ret;
> >
> > + if (!ns_capable(sock_net(skb->sk)->user_ns, CAP_NET_ADMIN)) {
> > + pr_warn_ratelimited("SA netlink: invalid perm for response:
> > `%s'.\n",
> > + current->comm);
> > + return -EPERM;
> > + }
> > +
> > spin_lock_irqsave(&ib_nl_request_lock, flags);
> > list_for_each_entry(query, &ib_nl_request_list, list) {
> > /*
>
> Maybe I'm missing something, but I thought you would want to check the
> capability with init_user_ns as the target, since the SA queries will
> affect all namespaces, not just the one that sent the response.
I'm not an expert in namespaces but these checks are only concerned with the
network namespace of the process which is acting as an SA proxy (via netlink).
AFAIK a user can't elevate a network namespace that the SA proxy is running in.
While you are correct that this data does affect all namespaces who are using a
particular port, this does not matter. The SA data for that port is applicable
no matter which network namespace an application running on that port is in.
Furthermore, the check in netlink_bind also uses the socket namespace to
restrict the use of multicast. This plus my checks should allow an admin to
place the SA proxy (ibacm in our test cases) in an alternate network namespace
if they so desire. But this is independent to the namespace which may be used
for data applications.
All that said, I did find the netlink_net_capable helper call which I should
have used instead. I'll work up a v2 today.
Thanks,
Ira
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
