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

[Eric W. Biederman]

Jason Gunthorpe <jgg at nvidia.com> writes:

> On Fri, Apr 25, 2025 at 10:32:27AM -0500, Eric W. Biederman wrote:
>> > That seems like splitting nits. Can I do current->XXX->user_ns and get
>> > different answers? Sounds like yes?
>> 
>> Totally.
>> 
>> current->cred->user_ns (aka current_user_ns) is the what the process
>> has.
>
> Well, this is the head hurty bit. "cred->user_ns" is not what the
> process "has" if the kernel is checking resource->netns->user_ns for
> the capability checks and ignores cred->user_ns?

resource->net->user_ns CAP_XXXX is what the process needs.

current->cred->user_ns and current->cred->cap_effective
are what the process has.

> How does a userspace process actually know what its current
> capabilties are? Like how does it tell if CAP_NET_XX is actually
> available?

It looks in current->cred.  In current->cred it finds bits
set in cap_effective, and a user_ns.

Ultimately all capable calls make their way down into
cap_capable_helper.  The cap_capable_helper checks to see if the user
namespace that is wanted (aka from the resource) matches the cred's user
namespace.  If the namespaces match then the bits in cap_effective
are checked.

There are a few more checks that make nested user namespaces work.


> What about something like CAP_SYS_RAWIO? I don't think we would ever
> make that a per-userns thing, but as a thought experiment, do we check
> current->XXX->user_ns or still check ibdev->netns->XX->user_ns?
>

Oh.  CAP_SYS_RAWIO is totally is something you can have.  In fact
the first process in a user namespace starts out with CAP_SYS_RAWIO.
That said it is CAP_SYS_RAWIO with respect to the user namespace.

What would be almost certainly be a bug is for any permission check
to be relaxed to ns_capable(resource->user_ns, CAP_SYS_RAWIO).

>> > Is it the kernel's struct ib_device? It has a netns that is captured
>> > at its creation time.
>> 
>> Yes.  Very much so.
>
> Okay.. And looking at this more we actually check that the process
> that opens /dev/../uverbsX has the same net_ns as the ib_device:

At which point I see how different the ib_device model is from
everything else..

ib_dev only sometimes belongs to a network namespace
(ib_devices_shared_netns).  The rest of time they are independent of the
network namespaces.

I don't know what an infiniband character device refers to.  Is it an
attachment of a physical cable to the box like a netdevice?  Is it an
infiniband queue-pair?

Given that the character device names aren't properly attached to a
network namespace it seems reasonable to ensure that you can only
open infiniband devices that are in your network-namespace (when
that is enabled).

The names (device major and minor) not living in a network namespace
mean that there can be problems for CRIU to migrate a infiniband device,
as it's device major and minor number are not guaranteed to be
available.  Perhaps that doesn't matter, as the name you open is on a
filesystem.  *Shrug*

> static int ib_uverbs_open(struct inode *inode, struct file *filp)
> {
> 	if (!rdma_dev_access_netns(ib_dev, current->nsproxy->net_ns)) {
> 		ret = -EPERM;
>

> bool rdma_dev_access_netns(const struct ib_device *dev, const struct net *net)
> {
> 	return (ib_devices_shared_netns ||
> 		net_eq(read_pnet(&dev->coredev.rdma_net), net));
>
> So you can say we 'captured' the net_ns into the FD as there is some
> struct file->....->ib_dev->..->net_ns that does not change
>
> Thus ib_dev->...->user_ns is going to always be the user_ns of the
> netns of the process that opened the FD.

Nope.

There is no check against current->cred->user_ns.  So the check has
nothing to do with the credentials of the process that opened the
character device.

> So.. hopefully final question.. When we are in a system call context
> and want to check CAP_NET_XX should we also require that the current
> process has the same net ns as the ib_dev?

I want to say in general only for opening the ib_device.

I don't know what to say for the case where ib_devices_shared_netns is
true.  In that case the ib_device doesn't have a network namespace at
all, so at best it would appear to be a nonsense check.

I think you need to restrict the relaxation to the case where
ib_devices_shared_netns is false.

The network stack in general uses netlink to talk to network devices
(sockets are another matter), so this whole using character devices
to talk to devices is very weird to me.

Eric