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 BDBFDA0562; Fri, 19 Mar 2021 15:17:13 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4110240143; Fri, 19 Mar 2021 15:17:13 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mails.dpdk.org (Postfix) with ESMTP id 587984003F for ; Fri, 19 Mar 2021 15:17:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616163430; 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=YOiH/ur8rHUBG59HAenNKAdtduQXphOz6iCIn4fZD9s=; b=YOH4C8cBOp9ICJs6WGF3aIKt2oTn/a0BQztmpoXVSrkdk2tfq1h33pTmkLYtFvJZCL4Lxg PbEMQVnSQVr4AqfQhUsuKUqLS0mjkts0/4FhUikNTMUHwDYrpmxgGeitlC43O1awl8AwWo OATbeXGsRRuyLWQ/BMFB0YFMwJf80zo= 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-440-a0NRMyJ8ONukiVY4vRKlrQ-1; Fri, 19 Mar 2021 10:17:06 -0400 X-MC-Unique: a0NRMyJ8ONukiVY4vRKlrQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 98C938189DB; Fri, 19 Mar 2021 14:17:05 +0000 (UTC) Received: from localhost (ovpn-112-193.ams2.redhat.com [10.36.112.193]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0A26A5D6D5; Fri, 19 Mar 2021 14:16:55 +0000 (UTC) Date: Fri, 19 Mar 2021 14:16:54 +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> MIME-Version: 1.0 In-Reply-To: <269ceb3d-3eda-ab5e-659d-e646a4c81957@ovn.org> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 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="Se8IsASoJjnqEDlE" 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" --Se8IsASoJjnqEDlE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. > >=20 > > 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. >=20 > 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. >=20 > This is actually a great extension for the SocketPair Broker Protocol. >=20 > Might even use SO_PEERSEC to enforce even stricter policies > based on selinux context. 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). Stefan --Se8IsASoJjnqEDlE--