Thread (38 messages) 38 messages, 9 authors, 2023-06-30

Re: [dpdk-dev] [RFC 0/4] SocketPair Broker support for vhost and virtio-user.

From: Ilya Maximets <i.maximets@ovn.org>
Date: 2021-03-19 15:37:08

On 3/19/21 3:16 PM, Stefan Hajnoczi wrote:
On Thu, Mar 18, 2021 at 09:14:27PM +0100, Ilya Maximets wrote:
quoted
On 3/18/21 8:47 PM, Ilya Maximets wrote:
quoted
On 3/18/21 6:52 PM, Stefan Hajnoczi wrote:
quoted
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/*<user-id>* 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help