Jason Gunthorpe <jgg@xxxxxxxxxx> writes: > 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. > > 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. > > 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. I guess I see a few places where inifiniband uses ioctl. There are also a lot of places where inifinband uses raw read/write on file descriptors. I think last time I looked infiniband wasn't even using ioctl. Now maybe using an ioctl is the best you can do at this point, because of some backwards compatibility. > 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. But that is exactly what the infiniband security check were are talking about appears to be doing. It is using the credentials of process A and failing after it was passed by process B. > 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. Which is fine as far as I understand it is fine. The creation check is what we were talking about. Taking from your example above. If process B with CAP_NET_RAW creates a FD for opening queue pairs and passes it to process A without CAP_NET_RAW then A is not able to create queue pairs. That is what the code in drivers/infiniband/core/ubvers_cmd.c:create_qp() currenty says. That is what has us confused. Exactly the kind of thing you said should not be happening is happening. Eric
