From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A7CC5A0524; Fri, 19 Mar 2021 17:02:10 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2ABDB140FC8; Fri, 19 Mar 2021 17:02:10 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mails.dpdk.org (Postfix) with ESMTP id 3F44E40143 for ; Fri, 19 Mar 2021 17:02:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616169728; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Sl0ljrOvMH8uq9YA/o+b/t/bij1lqge23jk5UmYe9is=; b=K1fDu74GwaSXi6D6w3dOwdHYVnvFNA/Vp0/HE4o/ivO8nJa0WNV/8UFSHdPNNH5i1APVdn m9n7O5XUW4g5fiDiIF45qPMF31nDpD7O8WPzPPJg1AvEfVVCieWw4oOll/LrQB3sTJl8lw L2cXEzW1BFbdiLAbXj8f1Tr1uSr6G/s= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-565-an1ex9B2NyykO67tP5q3Ew-1; Fri, 19 Mar 2021 12:01:33 -0400 X-MC-Unique: an1ex9B2NyykO67tP5q3Ew-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 808E484B9A0; Fri, 19 Mar 2021 16:01:31 +0000 (UTC) Received: from localhost (ovpn-112-90.ams2.redhat.com [10.36.112.90]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5A2D110016F8; Fri, 19 Mar 2021 16:01:23 +0000 (UTC) Date: Fri, 19 Mar 2021 16:01:22 +0000 From: Stefan Hajnoczi To: Ilya Maximets Cc: Maxime Coquelin , Chenbo Xia , dev@dpdk.org, Adrian Moreno , Julia Suvorova , =?iso-8859-1?Q?Marc-Andr=E9?= Lureau , Daniel Berrange Message-ID: References: <20210317202530.4145673-1-i.maximets@ovn.org> <269ceb3d-3eda-ab5e-659d-e646a4c81957@ovn.org> <4615ff01-105f-adc9-d2cd-816107bafa59@ovn.org> MIME-Version: 1.0 In-Reply-To: <4615ff01-105f-adc9-d2cd-816107bafa59@ovn.org> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=stefanha@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="l37ZES2HxlpiEGjv" Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [dpdk-dev] [RFC 0/4] SocketPair Broker support for vhost and virtio-user. X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" --l37ZES2HxlpiEGjv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 19, 2021 at 04:37:01PM +0100, Ilya Maximets wrote: > On 3/19/21 3:16 PM, Stefan Hajnoczi wrote: > > On Thu, Mar 18, 2021 at 09:14:27PM +0100, Ilya Maximets wrote: > >> On 3/18/21 8:47 PM, Ilya Maximets wrote: > >>> On 3/18/21 6:52 PM, Stefan Hajnoczi wrote: > >>>> On Wed, Mar 17, 2021 at 09:25:26PM +0100, Ilya Maximets wrote: > >>>> BTW what is the security model of the broker? Unlike pathname UNIX > >>>> domain sockets there is no ownership permission check. > >>> > >>> I thought about this. Yes, we should allow connection to this socket > >>> for a wide group of applications. That might be a problem. > >>> However, 2 applications need to know the 1024 (at most) byte key in > >>> order to connect to each other. This might be considered as a > >>> sufficient security model in case these keys are not predictable. > >>> Suggestions on how to make this more secure are welcome. > >> > >> Digging more into unix sockets, I think that broker might use > >> SO_PEERCRED to identify at least a uid and gid of a client. > >> This way we can implement policies, e.g. one client might > >> request to pair it only with clients from the same group or > >> from the same user. > >> > >> This is actually a great extension for the SocketPair Broker Protocol. > >> > >> Might even use SO_PEERSEC to enforce even stricter policies > >> based on selinux context. > >=20 > > Some piece of software or an administrator would need to understand the > > pid/uid/gid mappings used by specific containers in order to configure > > security policies in the broker like "app1 is allowed to connect to > > app2's socket". This is probably harder than it looks (and DBus already > > has everything to do this and more). >=20 > AFAIU, neither of orchestration solutions configures different access > rights for sockets right now. So, it, probably, should not be a big > problem for current setups. > > I'd expect pid/uid/gid being mapped to host namespace if SO_PEERCRED > requested from it. Interesting thing to check, though. >=20 > For DBus, as I mentioned in the other reply, IIUC, it will require > mounting /run/user/** or its bits and some other stuff to the > container in order to make it work. Also it will, probably, require > running containers in privileged mode which will wipe out most of the > security. Flatpak has sandboxed D-Bus for it application containers: https://docs.flatpak.org/en/latest/sandbox-permissions.html "Limited access to the session D-Bus instance - an app can only own its own name on the bus." I don't know about how it works. Stefan --l37ZES2HxlpiEGjv--