Qubes network server: 4.0 and beyond

[Manuel Amador (Rudd-O)]

Folks,

Given my own need to update my own machines, I've updated the Qubes network server code to work with 4.0 (and, soon, beyond 4.0).

Unlike the previous iteration (which used qrexec to set things up in NetVMs and AppVMs), this code re-scopes the feature to be limited to network-exposing machines directly attached to NetVMs, uses a proper agent that goes in the NetVM, and does not set up firewall rules in the AppVMs.

Unfortunately, this iteration of the code requires integration of a pull request in the Qubes OS admin component, responsible for informing the NetVM of which machines require exposure to the network:

• 4.0: https://github.com/QubesOS/qubes-core-admin/pull/336
• 4.1: https://github.com/QubesOS/qubes-core-admin/pull/337

The code that actually implements the correct behavior in NetVMs is here:

• https://github.com/Rudd-O/qubes-network-server/tree/r4.0
  

Additionally, I have no clue why the tests broke.

I could seriously use help getting this code in.  I'm happy to work with anyone on this issue.

Thanks in advance!

-- 
    Rudd-O
    http://rudd-o.com/

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, Apr 14, 2020 at 12:37:48AM +0000, Manuel Amador (Rudd-O) wrote:
> Folks,
>
> Given my own need to update my own machines, I've updated the Qubes
> network server code to work with 4.0 (and, soon, beyond 4.0).
>

> Unlike the previous iteration (which used /qrexec/ to set things up in

> NetVMs and AppVMs), this code re-scopes the feature to be limited to
> network-exposing machines directly attached to NetVMs, uses a proper
> agent that goes in the NetVM, and does not set up firewall rules in the
> AppVMs.

Sounds like a better approach.
Also, requiring a direct connection to NetVM IMO makes sense.

> Unfortunately, this iteration of the code requires integration of a pull
> request in the Qubes OS admin component, responsible for informing the
> NetVM of which machines require exposure to the network:
>

> * 4.0: https://github.com/QubesOS/qubes-core-admin/pull/336
> * 4.1: https://github.com/QubesOS/qubes-core-admin/pull/337

I see all you do is to react to some events and update qubesdb then. We
have specific API that allows you to do that from a 3rd-party extensions.
You can find documentation here (see also other about 'qubes' module,
but you got that part right already):
https://dev.qubes-os.org/projects/core-admin/en/latest/qubes-ext.html
and here is also real-world example:
https://github.com/QubesOS/qubes-core-admin-addon-whonix/
The files you need are:
- qubeswhonix/__init__.py - here is an actual extension (rename the
directory obviously)
- setup.py
plus a standard packaging stuff:
- Makefile
- rpm spec
- Makefile.builder

Also, thanks to Frédéric, we finally have working repository for
3rd-party packages, so if you want this to be conveniently installable
with just qubes-dom0-update, this would work now too :)

> The code that actually implements the correct behavior in NetVMs is here:
>

> * https://github.com/Rudd-O/qubes-network-server/tree/r4.0

>
> Additionally, I have no clue why the tests broke.

Tests there check for explicit list of qubesdb entries. You added some
more, so you would need to update the tests too. Plus, pylint complains
about too long function name.
Anyway, having this as a separate package will make this problem go
away.

> I could seriously use help getting this code in.  I'm happy to work with
> anyone on this issue.
>
> Thanks in advance!
>

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl6VEfsACgkQ24/THMrX
1ywdaAf5AYC8PH9w4dJ4jzfHxHIlTO/9JwXrRXzhC7eVgnuVbHjlMKLWWjUyEFrp
A4OvG7U/iI/gQmZAiXiMokRoepw4FNCoup8NnnNa2y6nFrlgd7tj3PIFBmb7W08Y
LYa2oC+P3buiPRlBjKMGpqSN4wqFDRa6biDDmOeiUyWhGugT12RtfFOJd8VBmIZ6
hYq3IkJXiL/xvikaty3Kx8s4TRttT0ix1QvdcML1RJk7IhM9JXzHrAhaDwljMtzX
m4XUR6CkHx63MO5Ahbc5LwW/7ufa5KHZvBXAmLtfBCW/Dbybf7Fh1OuMhUj7x+kx
uRCgVceP9xga8yfhrmXv2TCEsRNo2Q==
=WRTf
-----END PGP SIGNATURE-----

[Manuel Amador (Rudd-O)]

On 14/04/2020 01.29, Marek Marczykowski-Górecki wrote:

I see all you do is to react to some events and update qubesdb then. We
have specific API that allows you to do that from a 3rd-party extensions.
You can find documentation here (see also other about 'qubes' module,
but you got that part right already):
https://dev.qubes-os.org/projects/core-admin/en/latest/qubes-ext.html
and here is also real-world example:
https://github.com/QubesOS/qubes-core-admin-addon-whonix/
The files you need are:
 - qubeswhonix/__init__.py - here is an actual extension (rename the
    directory obviously)
 - setup.py
plus a standard packaging stuff:
 - Makefile
 - rpm spec
 - Makefile.builder

Thank you.  I will get right on this.

--
    Rudd-O
    http://rudd-o.com/

[Manuel Amador (Rudd-O)]

Good news.  Branch

* https://github.com/Rudd-O/qubes-network-server/tree/r4.0

is now updated to include the admin code as a dom0 add-on package, using the Qubes extension mechanisms.

Please, please, help me with a review of the code!

I will now close the pull requests I opened against the qubes-core-admin repository.

Work on >= 4.1 is ongoing.  For the time being, this is great progress, as I can finally configure my VMs correctly, and begin restoring network services that were previously protected by Qubes OS.

Thanks.

--
    Rudd-O
    http://rudd-o.com/