I don’t know what you meant by this, but More and more I’m confident that if you trust enough to your eth2usb adapter, this solution is even better then to expose HVM directly to the outer world. I am actively deploying it
1 Like
Thank you for posting this. I am actually having trouble understanding your setup. Does it avoid the problem of having to expose sys-usb to sys-net just to use a USB C-Ethernet adapter?
You’re welcome.
I didn’t understand @fsflover’s comment actually.
Sorry,but my English as not-a-first language makes me have trouble to understand your question.
My setup is simple. Separate sys-usb for the controller to which adapter is ported to. Created sys-net in PVH mode, attached adapter device from that controller/sys-usb to sys-net, configured sys-net (dvm-)template and connections as like the device is actually directly attached to sys-net and I’m online. sys-usb is not netVM for my sys-net.
Also,if needed to clarify, my sys-usb is not online at any moment.
My wild guess is that attacking adapter in sys-net while sys-net is in PVH mode is less trivial than to attack it when in HVM mode, and also poisoning the controller directly is probably possible only via channel-side attack (while it is still possible via attacking adapter’s firmware, but that is already less trivial than in HVM mode as I said).
Well, sometimes one “find time” at the office to do this kind of table …
How do I upload a spreadsheet in here ?
isn’t that an option/default to bind sys-net and sys-usb ?
If I remeber well, it’s even suggested during install.
trusting Qubes to not suggest a security downgrade
T15g gen1; P53; P15 gen1 have a 1GbE RJ45
T15g Gen2; P15 gen2 have a 2,5GbE RJ45
It’s an option. But having both USB controller(s) and internet handled in one qube looks like a disaster to me.
2 Likes
I tried to explain that a USB-C-to-Ethernet adapter can only be used if you have a USB controller and Internet connection in the same qube.
Ah, now I see what you meant. It’s unlike my setup, where sys-usb is offline.
So let me just make sure I understand because your setup sounds really good. You are on a typical laptop with a single USB bus controller.
You are using a USB-C-to-Ethernet adapter and you are doing it without combining sys-net and sys-usb which is what @fsflover is talking about.
Does this setup offer any type of limitations? Does sys-usb continue to work normally for other USB devices (e.g. storage, keyboard, mice).
To me too.
No. On a typical laptop with multiple controllers. Each controller has it’s own sys-usb.
No. I’m using the one one from the link above. I don’t have USB-C but I don’t think it matters.
I swear, for the third time, hahah
RAM? All my sys-* qubes are on no more than 500MB and based on minimals. I am not aware of any so far.
Actually, I have two of these adapters on the same controller which has two USB ports, and each adapter has it’s own sys-net in PVH mode, since I’m trying to squeeze the most of my internet connection that way. Both sys-nets work concurrently and no other device is allowed on that controller, especially storage or mouse/keyboard.
But you should keep in mind that:
- you have to trust your eth2usb adapter enough to use this
- I endlessly believe Qubes devs and their judgments. And they didn’t say anything if this ok or not. So, I took that as silence is the sign of approval, otherwise someone would already say this is stupid and dangerous.
It’s just that I don’t see how this should work with modern laptops which not rarely has only one USB controller and no RJ45 port. Well, “hide” all the devices in sys-usb behind correspondent PVH qube for each device, when possible.
Having one USB controller with no RJ45 port, meaning sys-usb online when my mouse/keyboard, external storage, etc all in the same qube just scares me, or even makes Qubes pointless to me. I don’t see the point of Qubes in protecting dom0 and templates.
Sorry if this question is redundant but I just want double check.
My laptop only has I believe one usb controller. Is it possible to follow your setup and preserve my default sys-usb to function normally (i.e. handle keyboard/mouse/storage/display in offline standard mode) and simultaneously following your guide to use USB-ethernet? Or does this require a computer with more than one USB controller to work as you describe?
I am also curious if you have a computer with multiple USB controller why don’t you just create multiple sys-usb and just make one of them online and the rest offline? I am confused as to what the advantage is doing this way you are doing when you have multiple usb controller and can compartmentalize.
You don’t believe. You open Device tab of any qube and look left and right for any controller that has USB in it’s name.
Especially in your case, I’d try to do that.
No.
?
I am compartmentalizing more than you are aware it looks. I just wrote that I have two sys-nets for two adapters from this sys-usb?
I wrote: I’m trying to protect my controller and the other device, by not making sys-usb online and the “protector” is sys-net in PVH mode to which adapter from sys-usb is persistently attached to. Please re-read that topic from the link above.
This setup does not look very compartmentalized to me. You USB device is passed to sys-net, so technically it could access the Internet and break the isolation of sys-usb. If you must use USB-ethernet with a single USB controller, then it’s probaby the best approach, but otherwise I would avoid that. See also: QSB-078: Linux kernel PV driver issues and LVM misconfiguration | Qubes OS.
1 Like
I agree, and I wrote above how I see it could happen. Also I agree and wrote this especially should be used in case of having one laptop per USB controller, as I like to say. But in my case, I can spare the controller to network devices only as I wrote, so very aware of possible consequences. But, have to practice for the future, because the next thing will be USB controller in the cloud, hahaha.
As I understand it, this is not related to the matter, and is actually the exact reason why whole Qubes defaults PVH and not PV and me using such a scenario described above.
So, I could say, that XSA is the reason why should I use it in a way above.
1 Like
In the default
Qubes OS configuration, this allows malicious sys-net, sys-firewall, and
sys-usb qubes to attack any qube to which they are connected
2 Likes
for PV backend?
Edit: Ah, I see what you mean - the default. And the default is HVM for sys-net, right? And I’m making PVH of it hopefully to gain attack less trivial?
AFAIK you can’t have PVH virtualization in any qube with connected devices.
Yes i know? That’s my strategy: move HVMs “behind” PVHs?
1 Like
Hello Community!
As a possible Qubes returner, I came about a good offer for a new laptop, for a Lenovo V15 Gen 2 ( AMD Ryzen 5 5500U). I was wondering whether this could be a good base to returning to Qubes. I have missed out several years of developments at Qubes, so all advice and feedback is welcome. At the same time I am trying to look up info but at first google did not give me clues about this laptop with Qubes. (also the Hardware Compatibility list is not containing any info on the V15 series)
Sincerely