linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serge@hallyn.com>
To: Parav Pandit <parav@nvidia.com>
Cc: Jason Gunthorpe <jgg@nvidia.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	"Serge E. Hallyn" <serge@hallyn.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 09:06:42 -0500	[thread overview]
Message-ID: <20250425140642.GC610516@mail.hallyn.com> (raw)
In-Reply-To: <PH8PR12MB720834D2635090B376790F30DC842@PH8PR12MB7208.namprd12.prod.outlook.com>

On Fri, Apr 25, 2025 at 01:54:07PM +0000, Parav Pandit wrote:
> 
> > From: Jason Gunthorpe <jgg@nvidia.com>
> > Sent: Friday, April 25, 2025 7:00 PM
> > 
> > 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? 
> I don't think so.
> 
> > We
> > are picking nsproxy because ib_dev has a net namespace affiliation?
> > 
> Yes.
> 
> After ruling out file's user ns, I believe there are two user ns.
> 
> 1. current_user_ns() 
> 2. current->nsproxy->net->user_ns.
> 
> In most cases #1 and #2 should be same to my knowledge.
> 
> When/if user wants to do have nested user ns, and don't want to create a new net ns, #2 can be of use.
> For example,
> a. Process1 starts in user_ns_1 which created net_ns_1
> b. rdma device is in net_ns_1
> c. Process1 unshare and moves to user_ns_2.
> d. For some reason user_ns_2 does not have the cap.

(d) is important.  "user_ns_2 does not have the cap" is imprecise.  Process1
after the unshare does have the cap against user_ns_2.  It does not have
it against user_ns_1, and since net_ns_1->user_ns == user_ns_1, that
means it loses privilege over net_ns_1.  Which is what we need.  Because
otherwise, an unprivileged user could simply unshare the user_ns, be root
there, and now tweak networking.

This all stems from the original requirements for user namespaces, which
were (off top of my head)

* unprivileged users must be able to create user namespaces
* root in a user namespace must be privileged over its resources
* root in a user namespace must have no privilege over any other resources
* user namespaces must nest

> By current UTS and other namespace semantics, since rdma device belongs to net ns, net ns's creator user ns to be considered.
> 
> I am unsure if doing #1 breaks any existing model.
> I like to get Eric/Serge's view also, if we should consider #1 or #2.

  reply	other threads:[~2025-04-25 14:06 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 [this message]
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=20250425140642.GC610516@mail.hallyn.com \
    --to=serge@hallyn.com \
    --cc=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 \
    /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).