Continuing the discussion from Qubes 4.0 Backup VMs slooow (gzip):
Openbsd support:
How to help?
What exactly is missing?
First idea would be a openbsd hvm that operates the network cards facing the evil.
Windows works with a hvm. So should openbsd as it gets access to real network boards.
Hold my beer:
A stupid approach that should work (I need to test it) would be to install openbsd on a hvm and include 2 nics (e.g. hme in my machine) and have one nic facing the evil and the other be connected to the nic (intel in my machine) which serves the netvm and which can be seen there as pci device.
BTW: I can use normal eth patch as gbit eth has auto mdi/x and the intel board is gbit eth.
This approach is lame, I know, but you should just hold my beer while I am doing it.
If it works, one could try to implement internal networking.
If you look at the issue relating to openbsd you will see that this is
a working system: I made a note on
this years ago, using a somewhat simpler approach, and routing through
sys-firewall.
It’s been discussed in the forum and the mailing lists a number of
times.
imo what is missing is the need for this in Qubes.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
1 Like
!!! YES THE NEEED!!!
I REALLY NEED OPENBSD, AS I DREAM IN PF, AND CAN NOT REST UNTIL OPENBSD IS
THE NETVM OF QUBES!!!
!!!
YEAH!
Really, openbsd is one of the finest systems that hit the internet, and I would really
need openbsd as net vm and as firewall vm.
BTW: pf includes nice load balancing.
Please include it asap, and I am willing to help where I can.
Cheers
luja
| unman Qubes Team
March 2 |
- | - |
A stupid approach that should work (I need to test it) would be to install openbsd on a hvm and include 2 nics (e.g. hme in my machine) and have one nic facing the evil and the other be connected to the nic (intel in my machine) which serves the netvm and which can be seen there as pci device.
If you look at the issue relating to openbsd you will see that this is
a working system: I made a note on
this years ago, using a somewhat simpler approach, and routing through
sys-firewall.
It’s been discussed in the forum and the mailing lists a number of
times.
imo what is missing is the need for this in Qubes.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
What you have repeated is your desire for it to be included in Qubes.
I asked what was the need for it in Qubes.
I specifically asked in the issues relating to openBSD what Qubes
problems would be resolved by inclusion of openBSD, and how it would
widen the appeal of Qubes - no one answered those questions.
When I comment in the Forum or in the mailing lists I speak for myself.
Compartmentalization? The more independent operating systems are used, the more diverse attacks against you must be performed.
2 Likes
It’s not the first line of defense you can win at… Otherwise, Qubes would be pointless… And it’s very not.
PF has unique features in packet filtering
For example filtering based on tcp fingerprinting.
block all on fxp0 os windows (iirc)
PF syntax is nice to read and to understand
Also I am sure that the openbsd kernel has better code quality compared to linux, so having a net vm based on openbsd facing the evil is an interesting alternative to having an old (fedora, debian) linux kernel facing it.
Also administering PF is nicer than administering iptables.
So if we include openbsd in qubes we can combine the strengths and rise the price tag for a successful attack as one would need to sucessfully exploit openbsd network stack which prove to be very reliable, and in case of success one is in a vm only.
If you use all linux an exploit mounted on the kernel goes through if you are using the same kernel everywhere. If you have diversity it is much more diffiult to exploit. Just think about functional safety: if you want to remove common errors change things. E.G. electric steering should be combined with a mechanical backup as both does not fail at the same time.
In an ideal world one would have a rule engine to produce pf and iprables rules and have both firewalls (pf@openbsd, iptables@linux) serialized. An exploit against one firewall would fail with the other while the rules (intended policy) are the same. But this would be much work, I know, but on the other hand be very interesting.
To get an Idea of a common rule generator:
http://fwbuilder.sourceforge.net/ seems to do the job, but as I looked at it last time the features were quite primitive and the project seems to be dead.
Step by step, first have an optional openbsd netvm.
But I feel that many exploits attack the webbrowser, e.g. firefox which is a beast laden with stupid features like custom colors, pocket and the like and as complexity kills, it is more likely for an entity to steal saved passwords to your web administered routers, your mail clients and the like by hacking your browser using ads, modified ip (governments can inject packets at your ISP or at the routers in between you and your peer like google, azure and the like services) compated with attacking an ip stack. But one can be abstinent from browsers like firefox but needs an ip stack!
But as you should be paranoid, you should not use firefox to administer infrastructure at all, yes you have an admin vm, but firefox is error prone, try some smaller browser like konqueror in your admin vm.
Back to the topic.
As in nature diversity provides more resilience. So having openbsd as an option helps you to choose to have a proxy vm running openbsd or fedora, or alpine, also with netvm. Openbsd compared to some linux distro is a big difference as it does not have a big fat linux kernel but a small openbsd kernel and kernel drivers for your hardware and other drivers for your needed protocols. So it is lighter and more flexible (small kernel with drivers vs fat kernel with everything discussion is like vim vs emacs-os)
I personally would prefer openbsd for netvm and in a second step for firewall vm (adaption for qubes can be some work to produce pf rules from the qubes tools).
Having a openbsd netvm would be perfect for the start
As I’ve explained, you can use an openbsd netvm right now.
As to the rest, I’ve said before that I cant see how using openbsd will
extend Qubes reach.
It’s true that including different OS will make attacks more difficult,
but this has to be balanced against the usability of the system.
If someone will write a simple user interface for PF, and incorporate it
in to the Qubes firewall tool, fine.
When I comment in the Forum or in the mailing lists I speak for myself.
Thanks for your Answer.
Using tools like FW builder one can generate PF rules using a point and click tool today. But the magic smoke escapes if you ate using such tools, as certain features of PF are not refered back in the tool.
https://ftp2.eu.openbsd.org/pub/OpenBSD/doc/history/pf-faq49.pdf
Also one could ask his favorite scientific institute to get this book:
https://www.oreilly.com/library/view/the-book-of/9781457185410/
There also was a nice tool to generate syntax graphs from the pf manpage, but I can not find it.
So usability and “lazyness” is no reason to reduce the quality of the product.
At least an optional openbsd netvm schould be included.
Regards
luja
I disagree completely with your view.
Qubes attempts to walk a fine line between security and usability.
The most secure OS is useless if it is not usable.
Any one is able to commit code to have a working *BSD template - no one
has done so.
I have shown how you can have a working openBSD HVM template, for any
one who would like one.
I do not believe that an openBSD template will in any way contribute to
making Qubes more widely adopted.
When I comment in the Forum or in the mailing lists I speak for myself.
1 Like
Please share the template vm
if you like, I can host it.
Regards
luja
No - I don’t want to encourage lazyness.
If you read in this very thread you will find instructions on how to
create a working openBSD gateway.
I think those notes are quite easy to follow.
You can create any HVM as a template - again, this has been covered
in the Forum many times.
Either create the qube with “HVM template” in the GUI, or at the command
line with qvm-create --class TemplateVM.
Start the new template with the installer attached -
qvm-start --cdrom IMAGE QUBE
Install the OS to the first drive : /dev/xvda
Now you have a working template and you can create HVMs based on it, as
normal - make sure you have kernel set to ‘’, so you boot from, and use,
the OS.
By default these will be disposables.
If you want permanence, then take steps to mount and use /dev/xvdb in
the qube.