Only use unix domain socket and named pipes for internal communication

[guillaumerose]

crc and his components should not bind any ports. It is a major security issue. Some security solutions deny it. Large corporation might be worried by that.

Current usage:

• Hyperkit and libvirt drivers bind random ports when crc needs to talk with them
• SSH port of the VM is opened although no user feature requires it (podman might in the future).

Hyper-V driver is already better with https://github.com/code-ready/machine/commit/af6c21be51dc2775397e2cad3e85cd17dd2255c1

vsock can help here:

• Hyperkit will no longer need to run as root and therefore the driver can be built-in like Hyper-V driver
• SSH can be done without exposing a port (by talking to a unix socket)

libvirt can be improved by using https://github.com/digitalocean/go-libvirt

[cfergeau]

libvirt can be improved by using https://github.com/digitalocean/go-libvirt

How does this relate to unix domain sockets/named pipes? crc uses qemu:///system for its libvirt interaction, which already goes through a unix socket.

[gbraad]

Can we break down the platfforms as individual tasks and keep this as an overview task?

[guillaumerose]

How does this relate to unix domain sockets/named pipes? crc uses qemu:///system for its libvirt interaction, which already goes through a unix socket.

Sorry for the lack of explanation: if we use digitalocean go-libvirt, we can statically compile the driver inside CRC and then, remove one more listening port (or we can use a unix domain socket).

[cfergeau]

Sorry for the lack of explanation: if we use digitalocean go-libvirt, we can statically compile the driver inside CRC and then, remove one more listening port (or we can use a unix domain socket).

The whole reasoning is - external drivers require the use of a listening port as the communication is not going through a unix domain socket. If we remove external drivers, we get rid of this listening port without needing to do the changes for unix domain sockets. However, the libvirt driver links with libvirt.so, so if we stop using an external driver, crc would start linking with libvirt.so. If we want to avoid this, one possible solution is to use digitalocean's libvirt implementation. Other ones are to dlopen the machine driver, or to help moving libvirt go bindings to transparently use dlopen.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.