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 11630A0524; Fri, 19 Mar 2021 16:37:07 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 86B20140F0B; Fri, 19 Mar 2021 16:37:06 +0100 (CET) Received: from relay10.mail.gandi.net (relay10.mail.gandi.net [217.70.178.230]) by mails.dpdk.org (Postfix) with ESMTP id BBC6440143 for ; Fri, 19 Mar 2021 16:37:04 +0100 (CET) Received: from [192.168.1.23] (ip-78-45-89-65.net.upcbroadband.cz [78.45.89.65]) (Authenticated sender: i.maximets@ovn.org) by relay10.mail.gandi.net (Postfix) with ESMTPSA id 6D00B24000C; Fri, 19 Mar 2021 15:37:02 +0000 (UTC) To: Stefan Hajnoczi , Ilya Maximets Cc: Maxime Coquelin , Chenbo Xia , dev@dpdk.org, Adrian Moreno , Julia Suvorova , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= , Daniel Berrange References: <20210317202530.4145673-1-i.maximets@ovn.org> <269ceb3d-3eda-ab5e-659d-e646a4c81957@ovn.org> From: Ilya Maximets Message-ID: <4615ff01-105f-adc9-d2cd-816107bafa59@ovn.org> Date: Fri, 19 Mar 2021 16:37:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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" 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. > > 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). 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. 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. Bets regards, Ilya Maximets.