Linux RDMA and InfiniBand development
 help / color / mirror / Atom feed
From: Parav Pandit <parav@nvidia.com>
To: <linux-rdma@vger.kernel.org>, <linux-security-module@vger.kernel.org>
Cc: <ebiederm@xmission.com>, Parav Pandit <parav@nvidia.com>
Subject: [PATCH] RDMA/uverbs: Fix CAP_NET_RAW check for flow create in user namespace
Date: Sat, 8 Mar 2025 20:06:02 +0200	[thread overview]
Message-ID: <20250308180602.129663-1-parav@nvidia.com> (raw)

A process running in a non-init user namespace possesses the
CAP_NET_RAW capability. However, the patch cited in the fixes
tag checks the capability in the default init user namespace.
Because of this, when the process was started by Podman in a
non-default user namespace, the flow creation failed.

Fix this issue by checking the CAP_NET_RAW networking capability
in the owner user namespace that created the network namespace.

This change is similar to the following cited patches.

commit 5e1fccc0bfac ("net: Allow userns root control of the core of the network stack.")
commit 52e804c6dfaa ("net: Allow userns root to control ipv4")
commit 59cd7377660a ("net: openvswitch: allow conntrack in non-initial user namespace")
commit 0a3deb11858a ("fs: Allow listmount() in foreign mount namespace")
commit dd7cb142f467 ("fs: relax permissions for listmount()")

Fixes: c938a616aadb ("IB/core: Add raw packet QP type")
Signed-off-by: Parav Pandit <parav@nvidia.com>

---
I would like to have feedback from the LSM experts to make sure this
fix is correct. Given the widespread usage of the capable() call,
it makes me wonder if the patch right.

Secondly, I wasn't able to determine which primary namespace (such as
mount or IPC, etc.) to consider for the CAP_IPC_LOCK capability.
(not directly related to this patch, but as concept)
---
 drivers/infiniband/core/uverbs_cmd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/core/uverbs_cmd.c b/drivers/infiniband/core/uverbs_cmd.c
index 5ad14c39d48c..8d6615f390f5 100644
--- a/drivers/infiniband/core/uverbs_cmd.c
+++ b/drivers/infiniband/core/uverbs_cmd.c
@@ -3198,7 +3198,7 @@ static int ib_uverbs_ex_create_flow(struct uverbs_attr_bundle *attrs)
 	if (cmd.comp_mask)
 		return -EINVAL;
 
-	if (!capable(CAP_NET_RAW))
+	if (!ns_capable(current->nsproxy->net_ns->user_ns, CAP_NET_RAW))
 		return -EPERM;
 
 	if (cmd.flow_attr.flags >= IB_FLOW_ATTR_FLAGS_RESERVED)
-- 
2.26.2


             reply	other threads:[~2025-03-08 18:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-08 18:06 Parav Pandit [this message]
2025-03-10 13:31 ` [PATCH] RDMA/uverbs: Fix CAP_NET_RAW check for flow create in user namespace Serge E. Hallyn
2025-03-10 14:47   ` Parav Pandit
2025-03-10 21:46     ` Serge E. Hallyn
2025-03-10 16:29 ` Eric W. Biederman
2025-03-10 17:48   ` Parav Pandit
2025-03-10 18:13     ` Eric W. Biederman
2025-03-11 11:32       ` Parav Pandit

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=20250308180602.129663-1-parav@nvidia.com \
    --to=parav@nvidia.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.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