From: Stefan Hajnoczi <stefanha@redhat.com>
To: Ilya Maximets <i.maximets@ovn.org>
Cc: "Maxime Coquelin" <maxime.coquelin@redhat.com>,
"Chenbo Xia" <chenbo.xia@intel.com>,
dev@dpdk.org, "Adrian Moreno" <amorenoz@redhat.com>,
"Julia Suvorova" <jusual@redhat.com>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Daniel Berrange" <berrange@redhat.com>
Subject: Re: [dpdk-dev] [RFC 0/4] SocketPair Broker support for vhost and virtio-user.
Date: Fri, 19 Mar 2021 14:16:54 +0000 [thread overview]
Message-ID: <YFSyVsNHAILvIQ8E@stefanha-x1.localdomain> (raw)
In-Reply-To: <269ceb3d-3eda-ab5e-659d-e646a4c81957@ovn.org>
[-- Attachment #1: Type: text/plain, Size: 1569 bytes --]
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).
Stefan
next prev parent reply other threads:[~2021-03-19 14:17 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-17 20:25 Ilya Maximets
2021-03-17 20:25 ` [dpdk-dev] [PATCH 1/4] net/virtio: fix interrupt unregistering for listening socket Ilya Maximets
2021-03-25 8:32 ` Maxime Coquelin
2021-04-07 7:21 ` Xia, Chenbo
2021-03-17 20:25 ` [dpdk-dev] [RFC 2/4] vhost: add support for SocketPair Broker Ilya Maximets
2021-03-17 20:25 ` [dpdk-dev] [RFC 3/4] net/vhost: " Ilya Maximets
2021-03-17 20:25 ` [dpdk-dev] [RFC 4/4] net/virtio: " Ilya Maximets
2021-03-18 17:52 ` [dpdk-dev] [RFC 0/4] SocketPair Broker support for vhost and virtio-user Stefan Hajnoczi
2021-03-18 19:47 ` Ilya Maximets
2021-03-18 20:14 ` Ilya Maximets
2021-03-19 14:16 ` Stefan Hajnoczi [this message]
2021-03-19 15:37 ` Ilya Maximets
2021-03-19 16:01 ` Stefan Hajnoczi
2021-03-19 16:02 ` Marc-André Lureau
2021-03-19 8:51 ` Marc-André Lureau
2021-03-19 11:25 ` Ilya Maximets
2021-03-19 14:05 ` Stefan Hajnoczi
2021-03-19 15:29 ` Ilya Maximets
2021-03-19 17:21 ` Stefan Hajnoczi
2021-03-23 17:57 ` Adrian Moreno
2021-03-23 18:27 ` Ilya Maximets
2021-03-23 20:54 ` Billy McFall
2021-03-24 12:05 ` Stefan Hajnoczi
2021-03-24 13:11 ` Ilya Maximets
2021-03-24 15:07 ` Stefan Hajnoczi
2021-03-25 9:35 ` Stefan Hajnoczi
2021-03-25 11:00 ` Ilya Maximets
2021-03-25 16:43 ` Stefan Hajnoczi
2021-03-25 17:58 ` Ilya Maximets
2021-03-30 15:01 ` Stefan Hajnoczi
2021-03-19 14:39 ` Stefan Hajnoczi
2021-03-19 16:11 ` Ilya Maximets
2021-03-19 16:45 ` Ilya Maximets
2021-03-24 20:56 ` Maxime Coquelin
2021-03-24 21:39 ` Ilya Maximets
2021-03-24 21:51 ` Maxime Coquelin
2021-03-24 22:17 ` Ilya Maximets
2023-06-30 3:45 ` Stephen Hemminger
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=YFSyVsNHAILvIQ8E@stefanha-x1.localdomain \
--to=stefanha@redhat.com \
--cc=amorenoz@redhat.com \
--cc=berrange@redhat.com \
--cc=chenbo.xia@intel.com \
--cc=dev@dpdk.org \
--cc=i.maximets@ovn.org \
--cc=jusual@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=maxime.coquelin@redhat.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).