nvme-tcp: fix selinux denied when calling sock_sendmsg

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>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Keith Busch <kbusch@kernel.org>

diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c
index feb2d7e17c4a14fc040c8038ff67e7f25d45fc95..542ffc921a3ff82e5838071130df00a32aa75cd9 100644 (file)
--- a/drivers/nvme/host/tcp.c
+++ b/drivers/nvme/host/tcp.c
@@ -1717,7 +1717,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,