I’m writing because I’m interested to work on FreeBSD jails as an alternative to Xen for isolation in QubesOS. And I have some questions about it, that someone on this list can maybe find the time to answer. My message to qubes-devel got bounced for some reasone, so I’m trying here.
I recently learned about FreeBSD’s jails, which provide isolation similar to a chroot environment, but with proper virtualization of the file system, the set of users and the networking subsystem.
I’ve also read about Joanna’s vision of Qubes air here.
Joanna argues that using Xen to achieve the separation is not really at the essence of Qubes, and she shows how the cloud or seperate raspberry Pis could also be used for this purpose in a future version of Qubes.
Along the same train of thought, it should be possible to build on top of FreeBSD’s jails, right? This is something that I would have interest in doing some work on, perhaps as part of my master thesis. My main motivation is to have a version of QubesOS with lower overhead on the virtualization technology. I’m aware that there may be differences in the protection offered for e.g. attacks on speculative execution between using Xen or FreeBSD’s jails for the isolation. So I don’t think one technology would make the other useless, but rather that they would be two options to choose from depending on the threat model.
My question is: Is it actually possible to start building this by implementing the things described under “Under the hood: qubes’ interfaces” in the “Qubes Air” blogpost for FreeBSD jails? Or is there something missing from the side of QubesOS that first needs some work? Or do you think this is a stupid idea to begin with?
FreeBSD jails requires the FreeBSD kernel and a pretty enormous codebase in standard libraries and executables to support it, even when stripped down to the bare minimum. Additionally, it relies in namespace segregation as the most significant mechanism for isolation (not unlike Linux containers). While it’s certainly possible to provide a certain degree of isolation through it, the attack surface is massive compared to a dedicated hypervisor like Xen. I don’t think you’d like to do that as a replacement for Xen in something like Qubes.
While it’s certainly possible to provide a certain degree of isolation
through it, the attack surface is massive compared to a dedicated
hypervisor like Xen. I don’t think you’d like to do that as a
replacement for Xen in something like Qubes.
I agree. Me looking into linux namespaces and FreeBSD jails some more
over the last weeks/months leaded to it finally clicking for me why
exactly QubesOS is using Xen. Before, I didn’t really understand what
the deal was: Isolation is isolation, right? The technology for it is
pretty much interchangable, I thought.
What I realized is that you want to have the isolation at the lowest
possible layer in the technology stack to decrease the attack
surface. That’s why QubesOS has it at the hypervisor level and all of
the burden of operating systems comes on top of that and is already
isolated. If you do it the other way around, the isolation depends on
all of these millions of lines of code.
Having understood that now, my motivation for working on something like
this has evaporated, since I think it’s the wrong approach.
