OpenKuBSD progress report

• Author: Solène
• Date: 16 June 2023
• Tags: openbsd security

Comment on Mastodon

Introduction

Here is a summary of my progress for writing OpenKuBSD. So far, I've had a few blockers but I've been able to find solutions, more or less simple and nice, but overall I'm really excited about how the project is turning out.

OpenKuBSD source code on tildegit.org (current branch == PoC)

As a quick introduction to OpenKuBSD in its current state, it's a program to install on top of OpenBSD, using mostly base system tools.

• OpenBSD templates can be created and configured
• Kubes (VMs) inherit an OpenBSD template for the disk, except for a dedicated persistent /home, any changes outside of /home will be reset on each boot
• Kubes have a nice name like "www.kube" to connect to
• NFS storage per Kube in /shared/ , this allows data to be shared with the host, which can then move files between Kubes via the shared directories
• Xephyr based compartimentalization for GUI display. Each program run has its own Xephyr server.
• Clipboard manipulation tool: a utility for copying the clipboard from one Xephyr to another one. This is a secure way to share the clipboard between Kubes without leakage.
• On-demand start and polling for ssh connection, so you don't have to pre-start a Kube before running a program.
• Executable `/home/openkubsd/rc.local` script at boot time to customize an environment at kube level rather than template level
• Desktop entry integration: a script is available to create desktop entries to run program X on Kube Y, directly from the menu

The Xephyr trick was hard to figure and implement correctly. Originally, I used `ssh -Y` which worked fine, and integrated very well with the desktop however:

• ssh -Y allows any window to access the X server, meaning any hacked VM could access all other running programs
• ssh -X is secure, but super bad: slow, can't have a custom layout, crashes when trying to do access X in some cases. (fun fact, on Fedora, ForwardX11Trusted seems to be set to Yes by default, so ssh -X does ssh -Y!)
• Xephyr worked, but running a program in it didn't use the full display, so a window manager was required. But all the tiling window managers I used (to automatically use all the screen) couldn't resize when Xephyr was resized.... except stumpwm!
• Stumpwm custom configuration to quit when it has no more window displayed. If you exit your programs then stumpwm quits then Xephyr stops.

Demo videos

OpenKuBSD: easily running programs from VMs

OpenKuBSD: NFS shares and desktop entries

OpenKuBSD: Xephyr implementation and clipboard helper

Roadmap

I'm really getting satisfied with the current result. It's still far from being ready to ship or feature complete, but I think the foundations are quite cool.

Next steps:

• tighten the network access for each Kube using PF (only NAT + host access + prevent spoofing)
• allow a Kube to not have NAT (communication would be restricted to the host only for ssh access), this is the most "no network" implementation I can achieve.
• allow a Kube to have a NAT from another Kube (to handle a Kube VPN for a specific list of Kubes)
• figure how to make a Tor VPN Kube
• allow to make disposable Kubes using the Tor VPN Kube network

Mid term steps:

• support Alpine Linux (with features matching what OpenBSD Kubes have)

Long term steps:

• rewrite all OpenKuBSD shell implementation into a daemon/client model, easier to install, more robust
• define a configuration file format to declare all the infrastructure
• release to wider audience
• open a bug tracker

Conclusion

The project is still in its beginning, but I made important progress over the last two weeks, I may reduce the pace here a bit to get everything stabilized. I started using OpenKuBSD on my own computer, this helps a lot to refine the workflow and see what feature matter, and which design is wrong or correct.

I hope you like that project as much as I do.