Encrypting or Securing VM-VM communications

[nurmagoz]

This is something sadly not being focused on from any hypervisor that i know to do that by default/design.

Thats mean any local app can sniff the connection/s and even manipulate them.

What we can do about it is either:

• Restricted file permission

We can make the connection isolated via unix socket file e.g file location /tmp/whonix-network.sock and we restrict this file.

and in GW:

-netdev socket,id=net0,unix=/tmp/whonix.sock,server=on

in WS:

-netdev socket,id=net0,unix=/tmp/whonix.sock,server=off

• Using stunnel or spiped on host

Mechanism how it will work:

1. The Workstation sends cleartext traffic to a local port (e.g., 5555).
2. stunnel listens on 5555, encrypts the traffic using TLS, and sends it to another local port (e.g., 6666).
3. A second stunnel process listens on 6666, decrypts the traffic, and hands it to the Gateway’s listening port.

But again somewhat we back to square one issue with local encryption how much it can be protected from local privileged attack (unless we can add linux file permission to where the encryption library (TLS) happening?).

• Internal VM to VM Encryption

This will neglect the reliability on KVM or anything on the host, instead it will use an internal tool to encrypt the data in WS (e.g wireguard), send the data encrypted to the GW then read it in the VM.

But this will break stream isolation or any control over any packet coming from WS, as they will be all encrypted before leaving WS.

Im not aware of any other method than these.

[HulaHoop]

1. We are not using sockets to connect VMs. Instead UDP tunneling has been selected since it is readily usable without problems

2. While possible as almost anything is on Linux, I am not seeing a compelling use case for default implementation of inter VM networking encryption. If the host is compromised, sniffing traffic between guests is the least of your problems.

[Patrick]

Unix domain socket files with restricted file permissions is the correct solution.

Encryption would only be useful for Remote Whonix-Gateway.

@nurmagoz

• Internal VM to VM Encryption

This will neglect the reliability on KVM or anything on the host, instead it will use an internal tool to encrypt the data in WS (e.g wireguard), send the data encrypted to the GW then read it in the VM.

But this will break stream isolation or any control over any packet coming from WS, as it will be all encrypted before leaving WS.

Stream isolation doesn’t necessarily break. The IP to IP encryption would be at a lower level (such as VPN). But VM to VM isn’t a great solution anyhow because then a secret has to be securely shared between the VMs. For example “copy key fingerprint in Whonix-Gateway, paste in specific file inside Whonix-Workstation”.

Incomplete documentation:

Connections between Whonix-Gateway ™ and Whonix-Workstation ™

[HulaHoop]

Untested. Also would require getting qemu-bridge-helpler working somehow before being able to create the required network bridges

Transparent Wireguard Networks in KVM

Alternatively for this to work with the current unprivileged VM model you’d theoretically run something like this:

[HOST 1: WhonixWorkstation VM → Wireguard Gateway VM] --Phyisical-LAN-> [HOST 2: Wireguard running on Whonix Gateway]

[nurmagoz]

@HulaHoop

We are not using sockets to connect VMs

Oh Why?

@HulaHoop

Instead UDP tunneling has been selected since it is readily usable without problems

But you notice any service (malicious or not) can listen to the connection, as this method is not encrypted.

[nurmagoz]

@HulaHoop

Alternatively for this to work with the current unprivileged VM model you’d theoretically run something like this:

[HOST 1: WhonixWorkstation VM → Wireguard Gateway VM] --Phyisical-LAN-> [HOST 2: Wireguard running on Whonix Gateway]

Yeah, if you can document that somewhere so i can test it, then we solved this issue forever where no OS ever done it.