About me: My name is Solène Rapenne, pronouns she/her. I like learning and sharing knowledge. Hobbies: '(BSD OpenBSD Qubes OS Lisp cmdline gaming security QubesOS internet-stuff). I love percent and lambda characters. OpenBSD developer solene@. No AI is involved in this blog.

Contact me: solene at dataswamp dot org or @solene@bsd.network (mastodon).

You can sponsor my work financially if you want to help me writing this blog and contributing to Free Software as my daily job.

OpenKuBSD design document

Written by Solène, on 06 June 2023.
Tags: #openbsd #qubesos #security

Comments on Fediverse/Mastodon

1. 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.

2. 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).

3. 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
OpenKuBSD design diagram

4. 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

5. 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

6. Trivia §

I announced it as OpenKuBISD, but I prefer to name it OpenKuBSD :)