nixos/qemu-vm: add option "restrictNetwork"

[pacien]

This adds an option to the qemu virtualisation module to isolate the
guest's from the host's and outside networks.

This is particularly useful for development sandboxes for example.

The option is disabled by default to preserve the current behaviour.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/1669

[roberth]

Could you add a vm test with three nodes, for example

• client
• server
• restricted

client and restricted should execute the same code, but on client it succeeds, whereas on restricted it does not.

[pacien]

Quoting Robert Hensing (2023-01-08 14:09:14)

Could you add a vm test with three nodes, for example - `client` - `server` - `restricted` `client` and `restricted` should execute the same code, but on `client` it succeeds, whereas on `restricted` it does not.

The option prevents a VM from reaching its host and the outside world. But it does not prevent a VM from reaching another VM through a virtual interface. So, `client` and `restricted` would both be able to reach the `server` VM here. Is there a way to test whether a VM can reach the test driver host?

[minijackson]

I'm not sure how we would test that, as the fact that today the QEMU VM can't access the global network is a consequence of the sandboxing, not the QEMU configuration. Maybe be trying to access the VM from outside the VM, but I think it would mean either not using the test infrastructure, or doing some changes to it.

[roosemberth]

Idea: Create a SLiRP network that subsequent VMs can join:

Node creating the network:

qemu-system
 ...
 -nic hubport,hubid=1,id=n1,mac=DE:AD:BE:EF:00:00
 -netdev socket,id=netsock,listen=:57300
 -netdev hubport,id=h0,hubid=1,netdev=netsock
 -netdev user,id=m1
 -netdev hubport,id=h1,hubid=1,netdev=m1

This command creates a virtual hub other VMs can connect to.
The option user, enables slirp on one of the ports.
The other port is exported to the guest.

Nodes attaching to the network

qemu-system
 ...
 -nic hubport,hubid=1,id=n1,mac=DE:AD:BE:EF:00:01
 -netdev socket,id=netsock,connect=localhost:57300
 -netdev hubport,id=h0,hubid=1,netdev=netsock

This command creates a virtual hub that connects to that of the first guest.
Notice the lack of the user. No effort is made by QEMU to provide a usable network other than linking the port to the first guest.

[pacien]

Quoting Roosemberth Palacios (2023-01-10 06:58:14)

Idea: Create a [SLiRP](https://wiki.qemu.org/Documentation/ Networking#User_Networking_.28SLIRP.29) network that subsequent VMs can join: [...]

If I understand this correctly, this seems equivalent to what the test-driver does to connect the different VMs together in their `virtualisation.vlans`. Issue is that this would still be inter-VMs network, not host and outside world networking, and thus not covered by the `restrict` flag that we want to test.

[roberth]

Perhaps you could run a web server on the host at some non-privileged port? Perhaps python's http.server?
Indeed the server vm I suggested doesn't seem very useful, except perhaps to confirm that it is unaffected.

[pacien]

Quoting Robert Hensing (2023-01-11 01:11:36)

Perhaps you could run a web server on the host at some non-privileged port? Perhaps python's [`http.server`](https://docs.python.org/3/library/http.server.html)?

I cannot find a suitable option in the testing module to run things on the host (within the sandbox) without bypassing the test-driver. What would be the correct way to run this on the host? How would one also get an internally routable IP address within the sandbox, without involving any of qemu's virtual networking, which would not be affected by the option?

[roberth]

What would be the correct way to run this on the host?

Anything that works I'd say. os.system() or spawning the thing in a separate thread.
I don't think we need a special method for this. cc @tfc

How would one also get an internally routable IP address within the sandbox,

I suppose only the loopback interface may be suitable for this. Is it possible for qemu's internal networking to perform NAT to expose the host loopback interface as a different address to the VMs?

The wiki seems to suggest that the loopback interface is treated no differently by the option:

You can isolate the guest from the host (and broader network) using the restrict option.

[tfc]

What would be the correct way to run this on the host?

Anything that works I'd say. os.system() or spawning the thing in a separate thread.
I don't think we need a special method for this. cc @tfc

I second that. We don't need extra code for that.

[pacien]

Test added as suggested!

[roberth]

This is fantastic. Thank you @pacien!