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

Parav Pandit parav at nvidia.com
Tue Mar 18 12:30:18 UTC 2025



> From: Jason Gunthorpe <jgg at nvidia.com>
> Sent: Tuesday, March 18, 2025 4:51 PM
> 
> On Tue, Mar 18, 2025 at 03:43:07AM +0000, Parav Pandit wrote:
> 
> > > I would say no, that is not our model in RDMA. The process that
> > > opens the file is irrelevant. We only check the current system call
> > > context for capability, much like any other systemcall.
> > >
> > Eric explained the motivation [1] and [2] for this fix is:
> > A lesser privilege process A opens the fd (currently caps are not
> > checked), passes the fd to a higher privilege process B.
> 
> > And somehow let process B pass the needed capabilities check for
> > resource creation, after which process A continue to use the resource
> > without capability.
> 
> Yes, I'd say that is fine within our model, and may even be desirable in some
> cases.
>
Is this subsystem specific?
I was thinking it is generic enough to all configurations done through ioctl().
For example, I don't see any difference between [1] and rdma.

[1] https://github.com/torvalds/linux/blob/76b6905c11fd3c6dc4562aefc3e8c4429fefae1e/block/ioctl.c#L441
 
> We don't use a file descriptor linked security model, it is always secured based
> on the individual ioctl system call. The file descriptor is just a way to route the
> system calls.
If I understood right, Eric suggests to improve this model by file level additional checks.

> 
> The "setuid cat" risk is interesting, but we are supposed to be preventing that
> by using ioctl, no 'cat' program is going to randomly execute ioctls on stdout.
> 
> You would not say that if process B creates a CAP_NET_RAW socket FD and
> passes it to process A without CAP_NET_RAW then A should not be able to
> use the FD.
Well, process B is higher privilege which shared the socket FD.

This is what I was asking in this patch to Eric above, should we have the min() check of both the process?

Or may be sharing the fd is somewhat special case, and generically it should be check when sharing the fd itself?

Each has tradeoffs; would like to understand what is the current generic model that we can adopt in rdma subsystem too.

> 
> The same principle holds here too, the object handles scoped inside the FD
> should have the same kind of security properties as a normal FD would.
> 
> Jason



More information about the Linux-security-module-archive mailing list