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

[Parav Pandit]

> From: Serge E. Hallyn <serge at hallyn.com>
> Sent: Friday, April 25, 2025 7:37 PM
> 
> On Fri, Apr 25, 2025 at 01:54:07PM +0000, Parav Pandit wrote:
> >
> > > From: Jason Gunthorpe <jgg at nvidia.com>
> > > Sent: Friday, April 25, 2025 7:00 PM
> > >
> > > 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?
> > I don't think so.
> >
> > > We
> > > are picking nsproxy because ib_dev has a net namespace affiliation?
> > >
> > Yes.
> >
> > After ruling out file's user ns, I believe there are two user ns.
> >
> > 1. current_user_ns()
> > 2. current->nsproxy->net->user_ns.
> >
> > In most cases #1 and #2 should be same to my knowledge.
> >
> > When/if user wants to do have nested user ns, and don't want to create a
> new net ns, #2 can be of use.
> > For example,
> > a. Process1 starts in user_ns_1 which created net_ns_1 b. rdma device
> > is in net_ns_1 c. Process1 unshare and moves to user_ns_2.
> > d. For some reason user_ns_2 does not have the cap.
> 
> (d) is important.  "user_ns_2 does not have the cap" is imprecise.  Process1
> after the unshare does have the cap against user_ns_2.  It does not have it
> against user_ns_1, and since net_ns_1->user_ns == user_ns_1, that means it
> loses privilege over net_ns_1.  Which is what we need.  Because otherwise, an
> unprivileged user could simply unshare the user_ns, be root there, and now
> tweak networking.
>
Effectively, since process_1 lost the privilege in user_ns_1 after step #c, 
if user wants to tweak networking, it must have a rdma device in net_ns_2, created by the user_ns_2.
Right?
 
> This all stems from the original requirements for user namespaces, which
> were (off top of my head)
> 
> * unprivileged users must be able to create user namespaces
> * root in a user namespace must be privileged over its resources
> * root in a user namespace must have no privilege over any other resources
> * user namespaces must nest
> 
> > By current UTS and other namespace semantics, since rdma device belongs
> to net ns, net ns's creator user ns to be considered.
> >
> > I am unsure if doing #1 breaks any existing model.
> > I like to get Eric/Serge's view also, if we should consider #1 or #2.