From: "Eric W. Biederman" <ebiederm@xmission.com>
To: Parav Pandit <parav@nvidia.com>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
Jason Gunthorpe <jgg@nvidia.com>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>,
Leon Romanovsky <leonro@nvidia.com>
Subject: Re: [PATCH] RDMA/uverbs: Consider capability of the process that opens the file
Date: Fri, 25 Apr 2025 10:46:59 -0500 [thread overview]
Message-ID: <871ptgi6q4.fsf@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <PH8PR12MB720850A641460067F7CC548DDC842@PH8PR12MB7208.namprd12.prod.outlook.com> (Parav Pandit's message of "Fri, 25 Apr 2025 15:27:40 +0000")
Parav Pandit <parav@nvidia.com> writes:
>> From: Serge E. Hallyn <serge@hallyn.com>
>> Sent: Friday, April 25, 2025 8:37 PM
>>
>> On Fri, Apr 25, 2025 at 11:24:29AM -0300, Jason Gunthorpe wrote:
>> > On Fri, Apr 25, 2025 at 09:01:44AM -0500, Serge E. Hallyn wrote:
>> > > On Fri, Apr 25, 2025 at 10:29:30AM -0300, Jason Gunthorpe wrote:
>> > > > On Fri, Apr 25, 2025 at 01:14:35PM +0000, Parav Pandit wrote:
>> > > >
>> > > > > 1. In uobject creation syscall, I will add the check current->nsproxy-
>> >net->user_ns capability using ns_capable().
>> > > > > And we don't hold any reference for user ns.
>> > > >
>> > > > This is the thing that makes my head ache.. Is that really the
>> > > > right way to get the user_ns of current? Is it possible that
>> > > > current has multiple user_ns's? We are picking nsproxy because
>> > > > ib_dev has a net namespace affiliation?
>> > >
>> > > It's not that "current has multiple user_ns's", it's that the
>> > > various resources, including other namespaces, which current has or
>> > > belongs to have associated namespaces.
>> >
>> > That seems like splitting nits. Can I do current->XXX->user_ns and get
>> > different answers? Sounds like yes?
>>
>> I don't think it's splitting nits. current->nsproxy->net_ns->user_ns is not
>> current's user namespace.
>>
>> > > current_user_ns() is the user namespace to which current belongs.
>> > > But if you want to check if it can have privilege over a resource,
>> > > you have to check whether current has ns_capable(resource->userns,
>> CAP_X).
>> >
>> > So what is the resource here?
>>
>> That's what I've been trying to get answered :)
>>
> A. When a raw socket is created to send a packet vis netdev
> (resource), the cap is checked against the process in [1].
No.
> [1] https://elixir.bootlin.com/linux/v6.14.3/source/net/ipv4/af_inet.c#L314
> Not against the netdev's dev_net().
There isn't a netdevide to check against.
The resource is the network namespace aka net.
The permission check is not solely against the processes credentials
in current->cred.
> B. Netdev's dev_net() is crossed checked to see if current process can access netdev ifindex or not in send() call.
>
> So resource was netdev, but literally the check is against the process
> cap.
Not at all. The process (user_ns,cap) pair in current->cred is checked
against the user_ns that owns the network namespace aka net->user_ns.
That current is used to find the network namespace is irrelevant for
the permission check.
> And considering above is right,
>
> I try to draw the parallels between the two types of network devices,
>
> the check for rdma raw QP (equivalent of raw socket),
> Should check similarly against the process's net->user_ns during QP creation time.
> This will match #A.
>
> And process to rdma access check should be a separate check #B.
The way you described it sounds wrong, but your conclusion of
what needs to be checked seems correct.
Eric
next prev parent reply other threads:[~2025-04-25 15:47 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
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 [this message]
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=871ptgi6q4.fsf@email.froward.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=jgg@nvidia.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