| 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 :) |