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

[Parav Pandit]

> From: Eric W. Biederman <ebiederm at xmission.com>
> Sent: Friday, April 25, 2025 9:17 PM
> 
> Parav Pandit <parav at nvidia.com> writes:
> 
> >> From: Serge E. Hallyn <serge at hallyn.com>
> >> Sent: Friday, April 25, 2025 8:37 PM
> >>
> >> On Fri, Apr 25, 2025 at 11:24:29AM -0300, Jason Gunthorpe wrote:
> >> > On Fri, Apr 25, 2025 at 09:01:44AM -0500, Serge E. Hallyn wrote:
> >> > > On Fri, Apr 25, 2025 at 10:29:30AM -0300, Jason Gunthorpe wrote:
> >> > > > On Fri, Apr 25, 2025 at 01:14:35PM +0000, Parav Pandit wrote:
> >> > > >
> >> > > > > 1. In uobject creation syscall, I will add the check
> >> > > > > current->nsproxy-
> >> >net->user_ns capability using ns_capable().
> >> > > > > And we don't hold any reference for user ns.
> >> > > >
> >> > > > This is the thing that makes my head ache.. Is that really the
> >> > > > right way to get the user_ns of current? Is it possible that
> >> > > > current has multiple user_ns's? We are picking nsproxy because
> >> > > > ib_dev has a net namespace affiliation?
> >> > >
> >> > > It's not that "current has multiple user_ns's", it's that the
> >> > > various resources, including other namespaces, which current has
> >> > > or belongs to have associated namespaces.
> >> >
> >> > That seems like splitting nits. Can I do current->XXX->user_ns and
> >> > get different answers? Sounds like yes?
> >>
> >> I don't think it's splitting nits.  current->nsproxy->net_ns->user_ns
> >> is not current's user namespace.
> >>
> >> > > current_user_ns() is the user namespace to which current belongs.
> >> > > But if you want to check if it can have privilege over a
> >> > > resource, you have to check whether current has
> >> > > ns_capable(resource->userns,
> >> CAP_X).
> >> >
> >> > So what is the resource here?
> >>
> >> That's what I've been trying to get answered :)
> >>
> > A. When a raw socket is created to send a packet vis netdev
> > (resource), the cap is checked against the process in [1].
> 
> No.
> 
> > [1]
> > https://elixir.bootlin.com/linux/v6.14.3/source/net/ipv4/af_inet.c#L31
> > 4
> > Not against the netdev's dev_net().
> 
> There isn't a netdevide to check against.
> 

> The resource is the network namespace aka net.
>
Don't find any difference for rdma either.
For rdma too network namespace is the resource.
 
> The permission check is not solely against the processes credentials in current-
> >cred.
> 
> > B. Netdev's dev_net() is crossed checked to see if current process can access
> netdev ifindex or not in send() call.
> >
> > So resource was netdev, but literally the check is against the process
> > cap.
> 
> Not at all.    The process (user_ns,cap) pair in current->cred is checked
> against the user_ns that owns the network namespace aka net->user_ns.
> 
> That current is used to find the network namespace is irrelevant for the
> permission check.
> 
> > And considering above is right,
> >
> > I try to draw the parallels between the two types of network devices,
> >
> > the check for rdma raw QP (equivalent of raw socket), Should check
> > similarly against the process's net->user_ns during QP creation time.
> > This will match #A.
> >
> > And process to rdma access check should be a separate check #B.
> 
> The way you described it sounds wrong, but your conclusion of what needs to
> be checked seems correct.
> 
> Eric
> 
Since you described that net namespace is the resource, 
current->nsproxy->net->user_ns seems correct for rdma case too.