What is the current security of Mirage & OpenBSD service Qubes compared to default?

I’ve implemented the Mirage OS firewall myself, with plans to reattempt the OpenBSD netvm.

My question is, are these two implementations confidently believed to be as or more secure than standard fedora/debian netvm/firewall?

I understand that Mirage offers a significantly reduced attack surface both with its code & the diversity of environments the attacker would have to exploit to get in, which is also the case for OpenBSD.

What I don’t understand is whether there are vulnerabilities introduced in the process making them work for Qubes, or is it simple enough that whatever their security value is independent of Qubes is what is found when they are implemented in Qubes, with no or limited potential of Qubes-specific introduction of vulnerabilities.

IN SHORT: What is the communities understanding of their comparative security value to the default options?

Thanks.

2 Likes

May be it is better to compare with the minimal versions of the Debian and Fedora templates, instead of the standard ones?

Hi @KarlinQubes, I’ve left that issue (OpenBSD as netvm for qubes-mirage-fw: Consider support for openbsd HVM as netvm · Issue #146 · mirage/qubes-mirage-firewall · GitHub) for a while, and I’m busy getting Ocaml5 and solo5 together. So you’re more than welcome if you want to step forward on that! :heart:
For my POV this work should also helps with another issue (loss of connectivity on upstream VM restart · Issue #156 · mirage/qubes-mirage-firewall · GitHub), I currently think that this will be achieved by some sortof merge in the Ocaml code of uplink.ml, client.ml and dao.ml.

About your question I think that the totally different code base and with memory safety for Ocaml runtime helps in security/exploitation. The Qubes specific part for mirage is really limited and seems safe so far, the xen part is much larger.

Best.

3 Likes