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 733BCA0524; Fri, 19 Mar 2021 17:03:08 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 506B3140FDC; Fri, 19 Mar 2021 17:03:08 +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 92B2F140FC8 for ; Fri, 19 Mar 2021 17:03:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616169786; 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=vqYA0mheWdTL2MS9gDw2bEVbMU+lmP8Yr9uoHISMbks=; b=PWYfInZNSwwnr7DI4I7C9gffFb25bskIJZ0h8q/9FNroyTYxHTkqFaLaDwnU30M2zX8hXr 6OAJzEDVPuAjWUjL0mej5thBeyOhJBpRtdFDPsLL6O1VZqi1DdUceNKKTzKJLMKhi5WMrf pVqpwRgOAyrdSI9tt+xcYUTYU2AJy8g= Received: from mail-io1-f70.google.com (mail-io1-f70.google.com [209.85.166.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-299-PUZc44B8OB2P33MnRQ6yRQ-1; Fri, 19 Mar 2021 12:03:04 -0400 X-MC-Unique: PUZc44B8OB2P33MnRQ6yRQ-1 Received: by mail-io1-f70.google.com with SMTP id d8so30266367ion.10 for ; Fri, 19 Mar 2021 09:03:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vqYA0mheWdTL2MS9gDw2bEVbMU+lmP8Yr9uoHISMbks=; b=HOj1S0iKD1/Jp7mUUmML44JNn2nAje5HE1Rt9id/4SbZSDiUDXxpxapXFl5YZIkq/e zInGG7wvHkQt/xXoBO1RaLlvO8hwrhNE+5piwNVEFj2OwZ2vWfK7Xp5ZgqrrV5g+h7SA 0xMD/bUYZtZTFgFPUrCpNjxaJpmGshVd7ydAybMLbJlQMYLM8GmHsA/Mqd1j5RIIGwpI qmz9f5gAHj4mAdAVSLtxiGpeGF3Y08vbstTPzpufsgcnvsyy0zgOTaBA4zqW1ljktQSS O7e72NL0XuBkWhf1rv3xKQLcdbsKyy+8JhGDat8nDi6vSFy5LaHqEDjKR+s9oSCGda60 vu6g== X-Gm-Message-State: AOAM530Ntz+QSM+EsmzZ2CYz606HGzAn8eWuXiRmgEYXIopAb+zc7LHz LqxnLc9z3VXHSjR/av4sMxrufa0e7iTm9XwUffQT7ZoZaMPQ9wrpxmEkxQSUZnvCfD3HqjqQiMb p79VvLXJY0OYF16O7agU= X-Received: by 2002:a02:8545:: with SMTP id g63mr1962602jai.79.1616169783839; Fri, 19 Mar 2021 09:03:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzm60PoT4OWSFGgtoU7Gqk8UNXq0VOZCmzR95XFmPKhleQrGHCapSQ7ioMqBGrhYIEua6T/lTJEzSh7INa5R6k= X-Received: by 2002:a02:8545:: with SMTP id g63mr1962595jai.79.1616169783666; Fri, 19 Mar 2021 09:03:03 -0700 (PDT) MIME-Version: 1.0 References: <20210317202530.4145673-1-i.maximets@ovn.org> <269ceb3d-3eda-ab5e-659d-e646a4c81957@ovn.org> <4615ff01-105f-adc9-d2cd-816107bafa59@ovn.org> In-Reply-To: <4615ff01-105f-adc9-d2cd-816107bafa59@ovn.org> From: =?UTF-8?B?TWFyYy1BbmRyw6kgTHVyZWF1?= Date: Fri, 19 Mar 2021 20:02:52 +0400 Message-ID: To: Ilya Maximets Cc: Stefan Hajnoczi , Maxime Coquelin , Chenbo Xia , dev@dpdk.org, Adrian Moreno , Julia Suvorova , Daniel Berrange Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=mlureau@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" 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" Hi On Fri, Mar 19, 2021 at 7:37 PM 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. > > > > 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. > Right, if you need to communicate across namespaces, then it becomes less common. However, having a DBus socket (as a private bus) exposed in the NS isn't going to be any different than having the broker socket exposed, unless I am missing something. You'll have the same issues discussed earlier about uid mapping, for peercred authentication to work.