
A unikernel firewall for QubesOS (2016) - luu
http://roscidus.com/blog/blog/2016/01/01/a-unikernel-firewall-for-qubesos/
======
0xff00ffee
I'm confused by this:

"In Qubes, NetVM acts as netback to FirewallVM, which acts as a netback in
turn to its clients. But in Qubes, NetVM is supposed to be untrusted! So, we
have code running in kernel mode in the (trusted) FirewallVM that is talking
to and trusting the (untrusted) NetVM!"

Is this true?

~~~
tenebrisalietum
FirewallVM is probably "in front of" the untrusted NetVM.

> we have code running in kernel mode

It's 2020. You have to understand there are 3 levels now - hypervisor, kernel,
user, not two anymore. You don't necessarily own the system unless you are on
hypervisor level. If you only do one thing in a VM, and don't rely too much OS
primitives like users, etc. to do it (as you may not in a pure networking
situation like routing, etc.), you can flatten kernel+user and increase
performance and not sacrifice security.

That being said I should read this article and will do so.

~~~
blattimwind
The real oops is that the boundary they are using as a trust boundary is not
considered a trust boundary by its developers. Plainly,

> the netback driver runs in dom0 and is fully trusted. It is coded to protect
> itself against misbehaving client VMs. Netfront, by contrast, assumes that
> netback is trustworthy. The Xen developers only considers bugs in netback to
> be security critical.

> What can an attacker do once they’ve exploited FirewallVM’s trusting
> netfront driver? Presumably they now have complete control of FirewallVM. At
> this point, they can simply reuse the same exploit to take control of the
> client VMs, which are running the same trusting netfront code!

------
alpn
2016

~~~
talex5
Indeed. The project has since moved under the mirage org on GitHub, and now
has several contributors:

[https://github.com/mirage/qubes-mirage-
firewall](https://github.com/mirage/qubes-mirage-firewall)

