[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250320063523.2201926-1-shaopeijie@cestc.cn>
Date: Thu, 20 Mar 2025 14:35:23 +0800
From: shaopeijie@...tc.cn
To: kbusch@...nel.org,
axboe@...nel.dk,
hch@....de,
sagi@...mberg.me
Cc: linux-nvme@...ts.infradead.org,
linux-kernel@...r.kernel.org,
zhang.guanghui@...tc.cn,
gechangzhong@...tc.cn,
Peijie Shao <shaopeijie@...tc.cn>
Subject: [PATCH] nvme-tcp: fix selinux denied when calling sock_sendmsg
From: Peijie Shao <shaopeijie@...tc.cn>
In a SELinux enabled kernel, socket_create() initializes the
security label of the socket using the security label of the
calling process, this typically works well.
However, in a containerized environment like Kubernetes,
problem arises when a privileged container(domain spc_t)
connects to an NVMe target and mounts the NVMe as persistent
storage for unprivileged containers(domain container_t).
This is because the container_t domain cannot access
resources labeled with spc_t, resulting in socket_sendmsg
returning -EACCES.
The solution is to use socket_create_kern() instead of
socket_create(), which labels the socket context to kernel_t.
Access control will then be handled by the VFS layer rather
than the socket itself.
Signed-off-by: Peijie Shao <shaopeijie@...tc.cn>
---
drivers/nvme/host/tcp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c
index 327f3f2f5399..71f7045881eb 100644
--- a/drivers/nvme/host/tcp.c
+++ b/drivers/nvme/host/tcp.c
@@ -1790,7 +1790,8 @@ static int nvme_tcp_alloc_queue(struct nvme_ctrl *nctrl, int qid,
queue->cmnd_capsule_len = sizeof(struct nvme_command) +
NVME_TCP_ADMIN_CCSZ;
- ret = sock_create(ctrl->addr.ss_family, SOCK_STREAM,
+ ret = sock_create_kern(current->nsproxy->net_ns,
+ ctrl->addr.ss_family, SOCK_STREAM,
IPPROTO_TCP, &queue->sock);
if (ret) {
dev_err(nctrl->device,
--
2.43.0
Powered by blists - more mailing lists