Running ethernet sys-net in PVH mode

General Discussion
1

After several months of learning Qubes, I realized that the ethernet sys-net (not to say wifi) is the weakest link in Qubes, only to find out that it was already been discussed here, which proves what I concluded:

I decided to start a new topic due to its visibility and the idea I got, but please merge it with above if you find it more appropriate.

Now, after thinking through and reading a lot, these are the facts:

  1. Ethernet is safer than internal or external wifi.

  2. Ethernet sys-net has to be ran in HVM mode and thus it’s attack surface is significant.

  3. Internal wifi has to be ran in HVM mode plus radio range, which make its attack surface bigger than ethernet’s.

  4. External wifi could be ran in PVH mode, by attaching it to sys-net-ext-wifi via sys-usb, This equation for attack surface would be:

    PVH - (radio range + bad USB)

    for which I am not sure if its attack surface is bigger than for internal wifi, so please share your thoughts on this.

Thinking on this, I thought maybe the smallest attack surface would be for the equation

  1. PVH - radio range + bad USB

which led me to the topic title and to this:

640Ă—640 80.3 KB

I tried this. I have created disposable sys-usb-to-RJ45-adapter , then I created disposable sys-net-to-RJ45-adapter running in PVH mode, attached ethernet cable from the router to it, and it works flawlessly.

Now, I am absolutely aware that I am not that smart to be the first to realize that this is maybe the safest option for our sys-net, but please let me know why and is running ethernet in HVM mode safer than running ethernet in PVH mode with taking the risk of a bad USB adapter firmware handled by correspondent sys-usb.

2

May I kindly ask someone, preferably from the Qubes team to reply on this? I wouldn’t want to use less secure Qubes due to a possible misapprehension.

3

well, I think you are only transfering the problem to sys-usb, that must be HVM in order to suppor the USB devices. (I am quite sure of this, but may be wrong)

The best measures to reduce attack surface are probably to implement sys-net as a minimal template based disposable appVM. Probably (and subject to debate) without passwordless-root installed.

My view (not too techical person in this field, so…) is that it would be useful to implement some kind of containment in the capabilities of the several parts of the appVM, like SE linux, similar to the approach google used is android. GrapheneOS VM comes to mind, but does not exist.

1 Like
4

Thanks for your reply @qubicrm. But, aren’t we reducing surface attack by avoiding direct attack to network adapter’s firmware in sys-net, at least? This way, attacker would need channel-side attack from sys-net to an usb adapter’s firmware residing in sys-usb, which is at least less trivial then when device is directly exposed in sys-net?

Using disposable netVMs are of course a-must, as I wrote it, but I don’t find it related to the specific idea.

5

I am not so sure. Again, I am not to techical and do not have a strong opinion. But I do worry a bit about USB attacks.
On the other hand, if you have a USB controller only for this task, that is, no other device plugged to the USB ports controlled by that USB controller, then your reason may hold.
One problem I see is that, at least for laptops, USB controller are scarce (I would like to haxe 3 or 4 controllers, and most laptops have 2 or even 1.
And in thar case you still have a HVM appVM, just is sys-USB and not sys-net. Is it harder for an atacker to target some bits of code in sys-usb through the ethernet connection? I really do nor know. But i feel that in either case: 1) you are already quite secure (unless you have some particularly demanding requirement) and 2)at this level, probably it would be wiser to start to remove permissions to every process running in the VM as aggressively as you can.
Sugest reading Linux | Madaidan's Insecurities . Of course, sandbox discussin there is mostly not applicable to Qubes (as a matter of fact, qubesOS seems to be the best solution to the problem), but some reasoning there may be useful to qubes anyway.

6

Thanks for your time @qubicrm.

Me too, especially because I am not tech savvy by any means. And that is why I started this topic. Yet, what we can read in official documentation is that

Most attacks on the NetVM and USB VM (but not all of them!) require being somewhat close to the target system, for example, being connected to the same Wi-Fi network, or in the case of a USB VM, having physical access to a USB port..

Well, my threat model pretty much excludes anyone else’s access to my usb port, so the biggest danger in my case can come from the device itself (and channel side attacks). And I wanted to get some advises on that.

Reading further

and regarding to what you wrote

And in that case you still have a HVM appVM, just is sys-USB and not sys-net. Is it harder for an attacker to target some bits of code in sys-usb through the ethernet connection?

I’m wondering is it really “just is sys-USB” what I found and is written in Joanna’s article? And in article’s conclusion I found something that gave me a hope and, again, an idea for this topic

With this approach (a dedicated USB domain) you can now delegate your 3G modem to the NetVM, and other USB devices, such as removable disks to other domains, e.g. for file exchange. This seems the most reasonable setup, although it requires that either 1) your laptop doesn’t have USB-connected keyboard, or 2) you don’t use internal USB devices connected to the same controller that your USB keyboard/touchpad from other domains than Dom0 (in practice: no 3G modem in NetVM).

which actually completely covers my case (look at the name of my sys-usb).

Thanks for the link. It just confirms what we more or less know or feel, and why we choose to use Qubes at the end of the day. I’ve read it with pleasure.

My threat model is rather somewhere between low and normal, probably much closer to former, so investing in 2) would be considered as excessive, but thanks for the idea.

What confuses me is the fact you mentioned, that modern computers get less and less not only less dangerous interfaces and drives (floppys, cd/dvd. RJ45, PS/2, etc) but also less usb ports and controllers, obviously to the point of one laptop per controller (intentionally not written vice-versa hahah), while everybody’s screaming how usb is bad, yet all the people use mostly usb keyboards and don’t find this topic (except you) worthy to say at least - the most stupid idea. Not because of me, but because of other newbies like me who will read this.

1 Like
7

Like the two of you I cannot judge the likelihood of either a WiFi/Ethernet nor a USB attack. This might be the reason this thread doesn’t get much attention: there might be very few people here (and in general) qualified to even utter an opinion.

I understand your original question. You are asking whether using an Ethernet-to-USB adapter via sys-usb is less likely to lead to a compromise then using the build-in Ethernet PCI device in a sys-net. You also state that in your particular thread model you can pretty much exclude physical attack on your USB interfaces. So it is quite possible that in your particular model, going the above way might make it a bit less likely for you to end up with compromised firmware and/or a compromised sys- qube.

However, the larger principles at play are:

  • compromise is always possible / even likely
  • how can we leverage Qubes OS architecture and tools to mitigate the effects of compromise?

The threads you worry about as far as I understand them:

attack → WiFi firmware → compromises sys-net → ???
attack → Eth firmware → compromises sys-net → ???
attack → USB firmware → compromises sys-usb → ???
attack → Eth firmware → USB firmware → compromises sys-usb → ???

So your idea might make the attack chain longer, but in the end we still end up worrying about a compromised sys-qube …

  • … because they are exposed to hardware interfaces / firmware
  • … because they have to run in HVM mode
  • … because infrastructure / hardware is fundamentally untrusted

  1. I make them disposable … that doesn’t prevent initial compromise and it doesn’t stop subsequent compromise, but at least I start with a clean slate (as far as the qube is concerned); it also doesn’t “fix” anything regarding the hardware interface firmware. So if the attacker gained persistence in the firmware this won’t help at all. But if not, I get a clean slate. So it’s worth doing (a bit).

  2. I consider them absolutely untrusted … in case of network traffic (sys-net) that means only encrypted connections; in case of sys-usb that means I wouldn’t e.g. mount an encrypted partition there or decrypt any files… it’s simply there to host usb-proxy and input-sender … nothing else

But what about an attacker with a XEN/Qubes OS exploit you ask?

Well for me that is the deal: I use Qubes OS as designed and increase my level of security to a reasonable level (given the untrusted hardware/interfaces/infrastructure, my knowledge level and limitations and available energy/time). There is residual risk and I trust that the experts in the core team do their very best to mitigate what they can. And then I stop worrying. :wink:

3 Likes
8

As usual @Sven, your responses are much appreciated, but the time even more. I agree with everything you wrote, except likelihood. I have no doubt it (will) happen(ed/s.). And I meant exclusively on the external attacks, not from the device itself (but even with it)
My doubt was when it happens to sys-net, is it safer for sys-net device not to be in sys-net, because as I see it, you’d need to escape from sys-net to sys-usb in order to attack the device, which I see it as less trivial, but I need thought exactly on this actually. This is in regard of an external attack. In a case of an already compromised device’s firmware attack, is it safer for sys-net (and our online activity accordingly) when this happens in sys-usb, because as I see it again, device’s firmware attack would need to escape from sys-usb to sys-net in order to endanger our online activity, by the device itself. Or our online activity can be endangered in sys-usb by the device itself? I couldn’t find an answer to this

For a lurker/watcher, I feel this the point (like in the movies, haha) when something has to happen or it’ll get boring.

So I will conclude with how I followed Qubes Os fundamentals thinking through this:

  • dom0 is the most critical part - let’s isolate it from all other VMs.
  • dom0 is the most critical part - let’s move out from it as much as possible hardware, even GPU and Audio.
  • vault usually contains most sensitive data - let’s isolate it from - the internet.

and this was mine continuation of the principals

  • sys-net isn't most critical, or the most valuable part of Qubes, but for sure is it's weakest link - let's move hardware from it too, and let’s discuss about trade-offs in this case (“So your idea might make the attack chain longer”), because I am not nearly competent to judge?

It’s not that I foresee something. It already happens - RJ45 port is and will be vanishing.

What will be Qubes OS Team’s approach regarding sys-net when wifi and/or usb inevitably become the only way to get online?

Somehow I feel we should keep our current routers and to buy these adapters while them still not being treated as valuable targets as for firmware poisoning.