Yeah… Hi. Is it possible for the Qubes team to release a Qubes version that just have the name openbsd in it? Like linux mint versions… Some linux mint version use debian. ( LMDE is a Linux Mint project which stands for “Linux Mint Debian Edition”.)
In what ways would Qubes be even greater if OpenBSD was integrated in Qubes? Qubes is already great in my opinion, but there’s way much more room for improvement in anything really… So Qubes could be like 4% of what it could be. Not that i’m saying it’s bad. Windows 10 would be like 0,00035% of what it could be in that expression. I’m exaggerating here about Qubes and my examples. Qubes is awesome!
Just saying… Imagine the thought of the Qubes idea in 200 years. That’s my point.
How would an openbsd netVM be a better solution then fedora or debian? Even dom0…
Plus disposable netvm even. sys-net. That sounds like security.
Operating systems are always evolving and designs… And it’s an experimental OS.
How would people not love qubes even more if there where builds so people could pick and choose?
2 or 3 max i guess… I’ve read about OpenBSD and that needs to be integrated in Qubes in my opinion. Even dom0 should use it…
Is this possible, if so, why has it not been done yet?
Might just be hard to do i don’t know. I understand if the people have much to do already with such an advanced OS though… Might be too much to ask to implement openBSD, but it would be better then fedora i’m guessing and it’s possible to blend different OSes in one OS which is cool.
If some have time, or when… If they feel like it. This is something i think should be very cool in Qubes. OpenBSD.
Thanks
edit: The power of the questions… Note to self.
It was mentioned many times here and on the mailing list. Profits of using OpenBSD as netvm are to small to anyone from qubes team port all the drivers and tools to BSD. The proposition of cooperation was sent to OpenBSD mailing list few years ago and nobody answers. So to make it happend someone with knowladge about the OpenBSD and Qubes/Xen should code it all, and nobody wants to do that.
Curent state is that You can easily run OpenBSD under Qubes as HVM. With small hack (you have to use OpenBSD netfront Xen driver as an netback since guy who wrote Xen drivers for OpenBSD implement only netfront not netback) you can use that HVM as netvm. But you will not have any qubes integration. Only networking and passing drives will work.
Other problem is that You can encounter problems with passed through NICs. For me both wifi and eth seems to work on bare OpenBSD but not work when passed through to OpenBSD VM.
Ok thanks for the answer… Yeah i bet that would be allot of work…
Good to know. So they have ported stuff to debian and fedora then, but not openBSD if i understand that right.
Well that explains much. It’s still good you can run it as HVM if the security would improve. But that might not be enough for a whole linux flavor release i understand that. Thanks
Fedora template is native to Qubes so no porting here. Porting tools to Debian was not such hard task, as porting to BSD since still it is a GNU/Linux distro so kernel and lots of stuff are the same/similar. BSD is a separate Unix familly so it is a much harder task.
Probably it will be the easiest for someone who developing for OpenBSD before, but as I wrote it looks like OpenBSD community is not interested in such cooperation.
I see growing interest for that template lately. @marmarek maybe there is some possibility to encourage OpenBSD community to improve Xen drivers or even port qubes agents?
Might have better hardware support and KVM virtualization and stuff and that might been why they picked fedora over debian then. With the Zen virtualization and all. I don’t know.
Ok, yeah i don’t know why the openbsd community don’t want to co-operate with that…
I also found this now… Everyone are free to have their opinions of-course.
Qubes might be the OS of the future. I just think the idea of it is brilliant… The design is nice and all. The only downside is the heavy resources, but it runs pretty good i think.
I have never used anything like it… feels like the new thing. Just easy to set up a cube for emulators, or whatever… Someone wrote it destroys his workflow online. I would say the opposite. He/she could focus on one cube at a time also… Now i got offtrack… TL:DR.
Yeah, i don’t know why some of them would not want to do that, apart from it’s allot to do. And i get that… A really complicated OS. But the goal is easiness right. Combining different hard tasks in an easy way. Don’t sound easy… I think it’s easier in the latest releases also… by the way. Good way of combining it all! Smooth. Plus the overview…
But yes, OpenBSD seems much requested… Might become something more later on who knows…
Well, considering that the majority of xen vulnerabilities affecting Qubes are related to vms with attached PCI devices, and that in default Qubes configuration sys-net is the only network facing vm with attached PCI device - it can be concluded that sys-net is the weakest link in Qubes.
So especial attention should be paid to securing sys-net as much as possible, and OpenBSD with its security track record seems to be the best candidate for the template. Especially if it can be made into a minimal template without root access like other minimal Qubes templates.
But I don’t know how good is OpenBSD at hardware support, wireless and all that. I personally delegated all my wireless/4g to a dedicated router, because wireless drivers are the weakest link in sys-net. I take compromised router over compromised dom0.
But anyway, I think OpenBSD would fit like a glove in Qubes. Pity that there is no enthusiasm from the OpenBSD side.
Isn’t the OpenBSD security track record mainly just the result of OpenBSD shipping with ssh as the only default enabled service?
“Only two remote holes in the default install, in a heck of a long time!” does this matter in regard to sys-net, does it run any services where Linux wouldn’t get to make the same claim?
Not keeping the entire system homogeneous probably comes with some downsides as well in terms of security considerations, having everything be Linux does remove some complexity.
I also don’t think OpenBSD makes xen or cpu exploits less deadly, I could be wrong on this, but I don’t think they are OS dependent.
Is there any known attack that would have been fully prevented by using OpenBSD?
QSBs always say that the potential attacker would first need to exploit the guest vm system to then exploit xen vulnerability.
Well, OpenBSD devs claim on their site that the source code undergoes “the never-ending comprehensive audit.”
Also they ship a hardened kernel by default.
Depends on the complexity of qubes tools I guess, if it would be much harder to maintain for both Linux and BSD.
When I read some more about OpenBSD it looks like it not as secure like most people think it is (mostly due that only default installation is taken in to the count when writing about such small number of critical vulnerabilities, but also since OpenBSD devs have their own definition of critical vulnerability, and that it lacks some modern security mechanisms). But still when only using “secured default” installation with addition of only qubes agents it probably will be much more secure then full flagged fedora. If it be more secure then minimal fedora I don’t know, but still it can add more diversity into Qubes so the potential attack should be better prepared.
As for drivers it is a problem in I think most of BSD systems, and even bigger in OpenBSD since sometimes vendors write and distribute drivers for FreeBSD themselves but not for OpenBSD. Also I tried to run OpenBSD HVM on my laptop, and drivers for both ethernet and wifi fails. Problem lies somewhere between OpenBSD drivers and Xen since they work for bare metal installation.
Yes, If You have luck You can make it work. For me the drivers for wifi/eth not work in combination with Xen. Also Xen driver for for OpenBSD lacks netback which is the cause of the hack proposed in those guide. Not to mention lack of any Qubes integration.
I would also like to see templates for one of the BSD implementations. Preferably OpenBSD or perhaps pfSense for firewall purposes. Compare the count of CVE entries for Fedora to BSD, that might be one of the reasons people want it.
By this, at best subconsciously, you’re insinuating or thinking that Qubes devs didn’t think through well enough when choosing defaults.
If I’d thinks so, I’d never, ever used Qubes then.
Oh, and guess what? dom0 is based on fedora-32! Now what? How exactly would anything else anywhere else would save you from this and so many CVEs directly related to the very core of Qubes?
The answer
… is there, but I’d like to hear what do you think first.
In February 2020, a developer directly sponsored by Netgate started to commit code for a WireGuard kernel module to FreeBSD.[16] By February 2021, the module was included in pfSense CE 2.5.0, pfSense Plus 21.02,[17] and scheduled for release in FreeBSD 13.0. WireGuard founder Jason Donenfeld reviewed the code only to find glaring issues including “random sleeps added to ‘fix’ race conditions, validation functions that just returned true, catastrophic cryptographic vulnerabilities, whole parts of the protocol unimplemented, kernel panics, security bypasses, overflows, random printf statements deep in crypto code, the most spectacular buffer overflows, and the whole litany of awful things.”
So I’m very skeptical to that projects if they done something like this before. For BSD as whole family as I wrote in previous posts there will be probably many more problems with drivers for all kinds of devices if any BSD will be chosen for sys-net replacement.
That whole FreeBSD story with that developer is worth to check. I mean the background. Every detail. Criminal case, prison time, money paid in bail, leaving the country, getting caught, etc. Just for a better understanding.
It’s easy to find all those details, search for: [WireGuard / Netgate /pfSense Drama : r/networking - Reddit]
In the thread there are other articles. Also on artechnica: Buffer overruns, license violations, and bad code: FreeBSD 13’s close call
Qubes is awesome!
I just think the idea of it is brilliant… The design is nice and all. The only downside is the heavy resources, but it runs pretty good i think.