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.