networking on Dom0 - can I have it please?

669 views
Skip to first unread message

Nom

unread,
Feb 25, 2016, 9:26:21 PM2/25/16
to qubes-users
Is there anyway to get networking on Dom0 to work?

Before everyone screams "UNACCEPTABLE!", (Don't pretend you weren't going to). I know it doesn't fit the security model of the OS. But my threat model - quite reasonably doesn't require it. I would like to be able to still have some of the benefits of the OS's secure design with the chosen compromise of networking in Dom0. So can we just leave it at; I need network access on Dom0 for "reasons", OK?

I tried running the old 'qubes-dom0-network-via-netvm' that was removed in this patch: https://github.com/QubesOS/qubes-core-admin/commit/bb9d8bbf7881ce13023ac905f98511beaeaaeae7

Running 'qubes-dom0-network-via-netvm up' it gets as far as doing 'modprobe xen-netfront' successfully and fails on line 70 when calling 'qvm_collection[0].attach_network(...)' and reports:
'Dom0 does not have libvirt object'.

Is there a work around?

Manuel Amador (Rudd-O)

unread,
Feb 25, 2016, 10:19:28 PM2/25/16
to qubes...@googlegroups.com
Marek, was this feature removed?

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

Marek Marczykowski-Górecki

unread,
Feb 25, 2016, 10:27:26 PM2/25/16
to Manuel Amador (Rudd-O), qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
As you can see in the linked commit - yes, it was intentionally removed.

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWz8YVAAoJENuP0xzK19cs8PsH/RbyvuJEmHxnhA84de+V9YL2
b8NAjb18ptos4/djU2a8gb+bR4jQgFoAfeWh+49f1ovZ1+14UV0fEeqRITkJEsbW
H/Mv7RnQtVGAnqbVk1szXv2Vl8E9oNI00MzSYUANL8KRIWtE/G1MVpXJN6fOiKCL
E0nfn9wdWGyy0x4W5+u2dRTJSaaC1JYAFiz2tHo8a9/T/DQkr0T6+YRKWU3vS1SG
EEPcrnbI4Y3QR2MvJC9xj34O13GTVD3kDgPJFLI7lOtdZKv+bSOQt9r4voB98m0l
Ri2HPItXoVcXA5kppffC/lcRMsVsKr4ZQggOzspgXPGTBrhsVt8ZPgzSTo+tH5M=
=AbVW
-----END PGP SIGNATURE-----

raah...@gmail.com

unread,
Feb 25, 2016, 10:28:14 PM2/25/16
to qubes-users, rud...@rudd-o.com
Why are you even using qubes?

Nom

unread,
Feb 25, 2016, 10:46:01 PM2/25/16
to qubes-users, raah...@gmail.com
On Friday, 26 February 2016 14:28:14 UTC+11, raah...@gmail.com wrote:
> Why are you even using qubes?

I believe that Marek even commented at some point that, should the user want to break the security model, they should have the option.

For instance I have a secondary Ethernet port on a Qubes machine, I want to connect to it over a isolated LAN from another computer (running Qubes) for the purpose of controlling it remotely.

Vít Šesták

unread,
Feb 26, 2016, 3:05:56 AM2/26/16
to qubes-users, zv.od...@gmail.com
On Friday, February 26, 2016 at 3:26:21 AM UTC+1, Nom wrote:
But my threat model - quite reasonably doesn't require it.

Do you trust the network and your DNS server? If you don't, you should not do this, because dom0 is based on F20, which did not receive the recent security update for glibc DNS vulnerability. While dom0 receives security updates for security-related components (e.g. Xen and Linux kernel), this vulnerability is out of such scope.

Maybe you could mitigate such vulnerability by some DNS server in sys-net (provided you trust sys-net), but there might be some other vulnerabilities.

My point is that while your security model might be reasonable for some situations, it might make the current Qubes less secure than standard Ubuntu (or <pick your favourite distro>) installation.

Regards,
Vít Šesták 'v6ak'

Alex

unread,
Feb 26, 2016, 3:10:50 AM2/26/16
to qubes...@googlegroups.com
So the question is still "why not a simple linux+xen without the Qubes
glue"? Like Vít Šesták said, you may consider an Ubuntu installation and
adding Xen, so you can have all the virtualization goodies you want,
with a better security level - the dom0 ubuntu will be able to update
itself, instead of the F20 in Qubes dom0.

My interpretation is that yes, if the user wants to tear apart
everything he can, in the sense that no piece of software prevents it
from doing that in an absolute manner.

But still, if you go on an adventure like this you are on your own, and
you should be able to debug and fix the problems you'll encounter with
little trouble for the others that are running on the provided pathway...

tl;dr: the question in your subject is too broad; please ask for
something specific like "can I restore the functionality removed with
this patch" or "how do I install libvirt in dom0 so that I can revert
this patch"

--
Alex

signature.asc

facu....@gmail.com

unread,
Jul 28, 2016, 7:38:41 PM7/28/16
to qubes-users, zv.od...@gmail.com
Nom, you found solution? I want to do the same :P

zv.od...@gmail.com

unread,
Jul 31, 2016, 7:59:19 AM7/31/16
to qubes-users, facu....@gmail.com
Sorry, never did find a solution.

It really would be nice to be able to use some form of networked desktop interface (RDP, KVM, etc) to control dom0. As the only Qubes compatible hardware I have is a big old dual Xeon blade server, that doesn't fit in my office. Considering the hardware limitations of Qubes. It makes sense to use server hardware with an ethernet connection to a thin client (like Raspberry Pi).

Community seems to think it's wrong.
Reply all
Reply to author
Forward
0 new messages