[PATCH] RDMA/uverbs: Consider capability of the process that opens the file
Serge E. Hallyn
serge at hallyn.com
Mon Apr 21 13:00:24 UTC 2025
On Mon, Apr 21, 2025 at 11:04:57AM +0000, Parav Pandit wrote:
>
> > From: Serge E. Hallyn <serge at hallyn.com>
> > Sent: Monday, April 21, 2025 8:43 AM
> >
> > On Fri, Apr 04, 2025 at 02:53:30PM +0000, Parav Pandit wrote:
> > > Hi Eric, Jason,
> >
> > Hi,
> >
> > I'm jumping back up the thread as I think this email best details the things I'm
> > confused about :) Three questions below in two different stanzas.
> >
> > > 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.
> >
> > Why does it need CAP_NET_RAW to create the resource, if the resource won't
> > be usable by a process without CAP_NET_RAW later anyway?
> Once the resource is created, and the fd is shared (like a raw socket fd), it will be usable by a process without CAP_NET_RAW.
> Is that a concern? If yes, how is it solved for raw socket fd? It appears to me that it is not.
>
> > Is that legacy
> > for the read/write (vs ioctl) case?
> No.
>
> > Or is it to limit the number of opened
> > resources? Or some other reason?
> >
> The resource enables to do raw operation, hence the capability check of the process for having NET_RAW cap.
Ok, so it seems to me that
1. the create should check ns_capable(current->nsproxy->net->user_ns, CAP_NET_RAW)
2. the read/write are a known escape, eventually to be removed?
3. the ioctl should check file_ns_capable(attrs->ufile->filp->f_cred->user_ns, CAP_NET_RAW)
Two notes about (3). First, note that it's different from what you had.
It explicitly checks that the caller has CAP_NET_RAW against the net
namespace that was used to open the file. Second, I'm suggesting this
because Jason does keep saying that ioctl is supposed to solve the
missing permission check. If it really is felt that no permission
check should be needed, that's a different discussion. I've just been
trying to figure out where the state should be tracked.
-serge
More information about the Linux-security-module-archive
mailing list