linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Parav Pandit <parav@nvidia.com>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"linux-security-module@vger.kernel.org"
	<linux-security-module@vger.kernel.org>,
	"serge@hallyn.com" <serge@hallyn.com>,
	Leon Romanovsky <leonro@nvidia.com>
Subject: Re: [PATCH] RDMA/uverbs: Consider capability of the process that opens the file
Date: Tue, 18 Mar 2025 19:57:09 -0300	[thread overview]
Message-ID: <20250318225709.GC9311@nvidia.com> (raw)
In-Reply-To: <87ldt2yur4.fsf@email.froward.int.ebiederm.org>

On Tue, Mar 18, 2025 at 03:00:15PM -0500, Eric W. Biederman wrote:

> 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.

Yeah, that's all deprecated now, and it had some major security issue
with the 'setuid cat' attack. IIRC it was mitigated by disallowing
read/write from a process with different credentials than the process
that opened the FD. This caused regressions which were resolved by
moving to ioctl.

Today you can compile the read/write interface out of the kernel - for
the last uh 6 years or so the userspace has exclusively used ioctl.

> > 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.

I'm not sure what you are refering too? The model should be that the
process invoking the system call is the one that provides the
capability set.

It is entirely possible that the code is wrong, but the above was the
intention.

> 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.

Yes that's right, because the FD itself has no security properties at
all, it is just a conduit for calling into the kernel.

Process A cannot create raw queue pairs in the same way that Process A
cannot create raw sockets, it doesn't matter what where the FD came
from.

> That is what the code in
> drivers/infiniband/core/ubvers_cmd.c:create_qp() currenty says.

I'm not sure what you are referring to here? That function is called
on the system call path, and at least the intention was that this:

        case IB_QPT_RAW_PACKET:
                if (!capable(CAP_NET_RAW))
                        return -EPERM;
                break;

Would check the current task invoking the system call to see if that
task has the required capability.

Jason

  reply	other threads:[~2025-03-18 22:57 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-13  5:08 [PATCH] RDMA/uverbs: Consider capability of the process that opens the file Parav Pandit
2025-03-17 19:31 ` Jason Gunthorpe
2025-03-18  3:43   ` Parav Pandit
2025-03-18 11:20     ` Jason Gunthorpe
2025-03-18 12:30       ` Parav Pandit
2025-03-18 12:44         ` Jason Gunthorpe
2025-03-18 20:00       ` Eric W. Biederman
2025-03-18 22:57         ` Jason Gunthorpe [this message]
2025-04-04 14:53           ` Parav Pandit
2025-04-04 15:13             ` Jason Gunthorpe
2025-04-06 14:15               ` Serge E. Hallyn
2025-04-07 11:16                 ` Parav Pandit
2025-04-07 14:46                   ` sergeh
2025-04-20 12:30                     ` Parav Pandit
2025-04-20 13:41                       ` Serge E. Hallyn
2025-04-20 17:31                         ` Parav Pandit
2025-04-07 16:12                   ` Jason Gunthorpe
2025-04-08 14:44                     ` Eric W. Biederman
2025-04-21  3:13             ` Serge E. Hallyn
2025-04-21 11:04               ` Parav Pandit
2025-04-21 13:00                 ` Serge E. Hallyn
2025-04-21 13:33                   ` Parav Pandit
2025-04-21 17:22                     ` Serge E. Hallyn
2025-04-22 12:46                       ` Jason Gunthorpe
2025-04-22 13:14                         ` Serge E. Hallyn
2025-04-22 16:11                           ` Jason Gunthorpe
2025-04-22 16:29                             ` Serge E. Hallyn
2025-04-23 12:41                               ` Parav Pandit
2025-04-23 14:46                                 ` Jason Gunthorpe
2025-04-23 15:43                                   ` Eric W. Biederman
2025-04-23 15:56                                     ` Parav Pandit
2025-04-23 16:45                                       ` Jason Gunthorpe
2025-04-24  9:08                                         ` Parav Pandit
2025-04-24 14:13                                           ` Jason Gunthorpe
2025-04-25 13:14                                             ` Parav Pandit
2025-04-25 13:29                                               ` Jason Gunthorpe
2025-04-25 13:54                                                 ` Parav Pandit
2025-04-25 14:06                                                   ` Serge E. Hallyn
2025-04-25 15:05                                                     ` Parav Pandit
2025-04-25 15:29                                                       ` Serge E. Hallyn
2025-04-25 13:59                                                 ` Serge E. Hallyn
2025-04-25 14:01                                                 ` Serge E. Hallyn
2025-04-25 14:24                                                   ` Jason Gunthorpe
2025-04-25 15:06                                                     ` Serge E. Hallyn
2025-04-25 15:27                                                       ` Parav Pandit
2025-04-25 15:46                                                         ` Eric W. Biederman
2025-04-25 16:16                                                           ` Parav Pandit
2025-04-25 15:32                                                     ` Eric W. Biederman
2025-04-25 16:21                                                       ` Jason Gunthorpe
2025-04-25 17:34                                                         ` Eric W. Biederman
2025-04-25 18:20                                                           ` Parav Pandit
2025-04-25 18:35                                                           ` Jason Gunthorpe
2025-04-27 14:30                                                             ` Serge E. Hallyn
2025-04-28 17:03                                                             ` Eric W. Biederman
2025-04-29  3:56                                                               ` Eric W. Biederman
2025-04-29 10:39                                                               ` Parav Pandit
2025-04-30  3:34                                                                 ` Eric W. Biederman
2025-04-30 12:14                                                                   ` Parav Pandit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250318225709.GC9311@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=ebiederm@xmission.com \
    --cc=leonro@nvidia.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=parav@nvidia.com \
    --cc=serge@hallyn.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).