From: Jason Gunthorpe <jgg@nvidia.com>
To: Parav Pandit <parav@nvidia.com>
Cc: "linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>,
"ebiederm@xmission.com" <ebiederm@xmission.com>,
"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 09:44:52 -0300 [thread overview]
Message-ID: <20250318124452.GO9311@nvidia.com> (raw)
In-Reply-To: <CY8PR12MB71958550549E3F0F016952B2DCDE2@CY8PR12MB7195.namprd12.prod.outlook.com>
On Tue, Mar 18, 2025 at 12:30:18PM +0000, Parav Pandit wrote:
>
>
> > From: Jason Gunthorpe <jgg@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?
Probably.. How a FD works and it's security model is very specific to
each FD type.
> 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
Isn't that the same thing? roset is an ioctl on a block char dev file
descriptor. It doesn't check the capability of the process that opened
the file.
> > 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.
Yes, but I'm not sure it is an improvement, or that it won't cause
regressions.
> > 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.
Yes, and?
> This is what I was asking in this patch to Eric above, should we have the min() check of both the process?
No. We don't do it above for sockets, we shouldn't do it for RDMA
objects either.
Jason
next prev parent reply other threads:[~2025-03-18 12:44 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 [this message]
2025-03-18 20:00 ` Eric W. Biederman
2025-03-18 22:57 ` Jason Gunthorpe
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=20250318124452.GO9311@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).