Title: OpenKuBSD design document | |
Author: Solène | |
Date: 06 June 2023 | |
Tags: openbsd qubesos security | |
Description: Let's partially reimplement QubesOS using OpenBSD o/ | |
# Introduction | |
I got an idea today (while taking a shower...) about _partially_ | |
reusing Qubes OS design of using VMs to separate contexts and programs, | |
but doing so on OpenBSD. | |
To make explanations CLEAR, I won't reimplement Qubes OS entirely on | |
OpenBSD. Qubes OS is an interesting operating system with a very | |
strong focus on security (from a very practical point of view ), but | |
it's in my opinion overkill for most users, and hence not always | |
practical or usable. | |
In the meantime, I think the core design could be reused and made it | |
easy for users, like we are used to do in OpenBSD. | |
# Why this project? | |
I like the way Qubes OS allows to separate things and to easily run a | |
program using a VPN without affecting the rest of the system. Using it | |
requires a different mindset, one has to think about data silos, what | |
do I need for which context? | |
However, I don't really like that Qubes OS has so many opened issues, | |
governance isn't clear, and Xen seems to be creating a lot of troubles | |
with regard to hardware compatibility. | |
I'm sure I can provide a similar but lighter experience, at the cost of | |
"less" security. My threat model is more preventing data leak in case | |
of a compromised system/software, than protecting my computer from a | |
government secret agency. | |
After spending two months using "immutables" distributions (openSUSE | |
MicroOS, Vanilla OS, Silverblue), where they all want to you use | |
root-less containers (with podman) through distrobox, I hate that idea, | |
it integrates poorly with the host, it's a nightmare to maintain, can | |
create issues due to different versions of programs altering your user | |
data directory, and that just doesn't bring anything much to the table | |
except allowing users to install software without being root (and | |
without having to reboot on those systems). | |
# Key features | |
Here is a list of features that I think good to implement. | |
* vmd based OpenBSD and Alpine template (installation automated), with | |
the help of qcow2 format for VMs, it's possible to create a disk based | |
on another, a must for using templates | |
* disposable VMs, they are started from the template but using a | |
derived disk of the template, destroyed after use | |
* AppVM, a VM created with a persistent /home, and the rest of the | |
system is inherited from the template using a derived qcow2 from | |
template | |
* VPN VMs that could be used by other VMs as their network source (Tor | |
VPN template should be provided) | |
* Simple configuration file describing your templates, your VMS, | |
packages installed (in templates), and which network source to use for | |
which VM | |
* Installing software in templates will create .desktop files in menus | |
to easily start programs (over `ssh -Y`) | |
* OpenBSD host should be USABLE (hardware acceleration, network | |
handling, no perf issues) | |
* OpenBSD host should be able to transfer files between VMs using ssh | |
* Audio disabled by default on VMs, sndio could be allowed (by the user | |
in a configuration file) to send the sound to the host | |
* Should work with at least 4 GB of memory (I would like to make just 2 | |
as a requirement if possible) | |
Some kind of quick diagram explaining relationship of various | |
components. This doesn't show the whole picture because it wouldn't be | |
easy to represent (and I didn't had time to try doing so yet): | |
OpenKuBSD design diagram | |
# What I don't plan to do | |
* HVM support and passthrough, this could be done one day if vmd | |
supports passthrough, but this creates too much problems, and only help | |
security for niche use case I don't want to focus on | |
* USB passthrough, too complex to implement, too niche use case | |
* VM RPC, except for the host being able to copy files from one vm to | |
the other using ssh | |
* An OpenBSD distribution, OpenKuBSD must be installable on top of | |
OpenBSD with the least friction possible, not as a separate system | |
* Support Windows guests | |
# Roadmap | |
The first step is to make a proof of concept: | |
* generate the OpenBSD template automatically | |
* being able to start a disposable VM using the OpenBSD template | |
* generate an OpenBSD Tor template | |
* being able to use it in the disposable VM | |
# Trivia | |
I announced it as OpenKuBISD, but I prefer to name it OpenKuBSD :) |