[PATCH] RDMA/uverbs: Consider capability of the process that opens the file

[Parav Pandit]

> From: sergeh at kernel.org <sergeh at kernel.org>
> Sent: Monday, April 7, 2025 8:17 PM
> 
> On Mon, Apr 07, 2025 at 11:16:35AM +0000, Parav Pandit wrote:
> > > From: Serge E. Hallyn <serge at hallyn.com>
> > > Sent: Sunday, April 6, 2025 7:45 PM
> > >
> > > On Fri, Apr 04, 2025 at 12:13:47PM -0300, Jason Gunthorpe wrote:
> > > > On Fri, Apr 04, 2025 at 02:53:30PM +0000, Parav Pandit wrote:
> > > > > To summarize,
> > > > >
> > > > > 1. A process can open an RDMA resource (such as a raw QP, raw
> > > > > flow entry, or similar 'raw' resource) through the fd using
> > > > > ioctl(), if it has the
> > > appropriate capability, which in this case is CAP_NET_RAW.
> > > > > This is similar to a process that opens a raw socket.
> > > > >
> > > > > 2. Given that RDMA uses ioctl() for resource creation, there
> > > > > isn't a security concern surrounding the read()/write() system calls.
> > > > >
> > > > > 3. If process A, which does not have CAP_NET_RAW, passes the
> > > > > opened fd to another privileged process B, which has
> > > > > CAP_NET_RAW, process B
> > > can open the raw RDMA resource.
> > > > > This is still within the kernel-defined security boundary,
> > > > > similar to a raw
> > > socket.
> > > > >
> > > > > 4. If process A, which has the CAP_NET_RAW capability, passes
> > > > > the file
> > > descriptor to Process B, which does not have CAP_NET_RAW, Process B
> > > will not be able to open the raw RDMA resource.
> > > > >
> > > > > Do we agree on this Eric?
> > > >
> > > > This is our model, I consider it uAPI, so I don't belive we can
> > > > change it without an extreme reason..
> > > >
> > > > > 5. the process's capability check should be done in the right
> > > > > user
> > > namespace.
> > > > > (instead of current in default user ns).
> > > > > The right user namespace is the one which created the net namespace.
> > > > > This is because rdma networking resources are governed by the
> > > > > net
> > > namespace.
> > > >
> > > > This all makes my head hurt. The right user namespace is the one
> > > > that is currently active for the invoking process, I couldn't
> > > > understand why we have net namespaces refer to user namespaces :\
> > >
> > > A user at any time can create a new user namespace, without creating
> > > a new network namespace, and have privilege in that user namespace,
> > > over resources owned by the user namespace.
> > >
> >
> > > So if a user can create a new user namespace, then say "hey I have
> > > CAP_NET_ADMIN over current_user_ns, so give me access to the RDMA
> > > resources belonging to my current_net_ns", that's a problem.
> > >
> > > So that's why the check should be ns_capable(device->net->user-ns,
> > > CAP_NET_ADMIN) and not ns_capable(current_user_ns,
> CAP_NET_ADMIN).
> > >
> > Given the check is of the process (and hence user and net ns) and not
> > of the rdma device itself, Shouldn't we just check,
> >
> > ns_capable(current->nsproxy->user_ns, ...)
> >
> > This ensures current network namespace's owning user ns is consulted.
> 
> No, it does not.  If I do
> 
> unshare -U
> 
> then current->nsproxy->user_ns is not my current network namespace's
> owning user ns.
>
It should be current->nsproxy->net->user_ns.
This ensures that it is always current network namespace's owning user ns is considered.
Right?

Sorry for the late response.
I wasn't well for few days followed by backlog.
 
> -serge