* [PATCH] nvme-tcp: fix selinux denied when calling sock_sendmsg
@ 2025-03-20 6:35 shaopeijie
2025-03-20 7:25 ` Christoph Hellwig
2025-03-20 20:15 ` Keith Busch
0 siblings, 2 replies; 4+ messages in thread
From: shaopeijie @ 2025-03-20 6:35 UTC (permalink / raw)
To: kbusch, axboe, hch, sagi
Cc: linux-nvme, linux-kernel, zhang.guanghui, gechangzhong,
Peijie Shao
From: Peijie Shao <shaopeijie@cestc.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@cestc.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
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] nvme-tcp: fix selinux denied when calling sock_sendmsg
2025-03-20 6:35 [PATCH] nvme-tcp: fix selinux denied when calling sock_sendmsg shaopeijie
@ 2025-03-20 7:25 ` Christoph Hellwig
[not found] ` <1382721899.82743.1742525374789.JavaMail.xmail@wm-2>
2025-03-20 20:15 ` Keith Busch
1 sibling, 1 reply; 4+ messages in thread
From: Christoph Hellwig @ 2025-03-20 7:25 UTC (permalink / raw)
To: shaopeijie
Cc: kbusch, axboe, hch, sagi, linux-nvme, linux-kernel,
zhang.guanghui, gechangzhong
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
Can you send a patch for the target side as well?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] nvme-tcp: fix selinux denied when calling sock_sendmsg
2025-03-20 6:35 [PATCH] nvme-tcp: fix selinux denied when calling sock_sendmsg shaopeijie
2025-03-20 7:25 ` Christoph Hellwig
@ 2025-03-20 20:15 ` Keith Busch
1 sibling, 0 replies; 4+ messages in thread
From: Keith Busch @ 2025-03-20 20:15 UTC (permalink / raw)
To: shaopeijie
Cc: axboe, hch, sagi, linux-nvme, linux-kernel, zhang.guanghui,
gechangzhong
On Thu, Mar 20, 2025 at 02:35:23PM +0800, shaopeijie@cestc.cn wrote:
> From: Peijie Shao <shaopeijie@cestc.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.
Thanks, applied to nvme-6.15.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] nvme-tcp: fix selinux denied when calling sock_sendmsg
[not found] ` <1382721899.82743.1742525374789.JavaMail.xmail@wm-2>
@ 2025-03-21 5:05 ` Christoph Hellwig
0 siblings, 0 replies; 4+ messages in thread
From: Christoph Hellwig @ 2025-03-21 5:05 UTC (permalink / raw)
To: 邵培杰
Cc: Christoph Hellwig, kbusch, axboe, sagi, linux-nvme, linux-kernel,
zhang.guanghui , gechangzhong
[note: your mail was mangled html, I'm trying to extract the answer]
On Fri, Mar 21, 2025 at 10:49:34AM +0800, 邵培杰 wrote:
> Sure. But on the target side, it's a bit different.
> All socket operations are done in the workqueue with domain kernel_t,
> the kernel_t can access other labels, so I think there's no issue.
Indeed.
> By
> the way, switching to sock_create_kern() could skip selinux avc
> permission check and might give a very small performance boost.
It also helps to avoid copy and paste bugs..
> I'll send an optimization patch later.
Thanks!
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-03-21 5:05 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-03-20 6:35 [PATCH] nvme-tcp: fix selinux denied when calling sock_sendmsg shaopeijie
2025-03-20 7:25 ` Christoph Hellwig
[not found] ` <1382721899.82743.1742525374789.JavaMail.xmail@wm-2>
2025-03-21 5:05 ` Christoph Hellwig
2025-03-20 20:15 ` Keith Busch
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox