1. Introduction §

I always had an interest for practical security on computers, being workstations or servers. Many kinds of threats exist for users and system administrators, it's up to them to define a threat model to know what is acceptable or not. Nowadays, we have choice in the operating system land to pick what works best for that threat model: OpenBSD with its continuous security mechanisms, Linux with hardened flags (too bad grsec isn't free anymore), Qubes OS to keep everything separated, immutable operating system like Silverblue or MicroOS (in my opinion they don't bring much to the security table though) etc...

My threat model always had been the following: some exploit on my workstation remaining unnoticed almost forever, stealing data and capturing keyboard continuously. This one would be particularly bad because I have access to many servers through SSH, like OpenBSD servers. Protecting against that is particularly complicated, the best mitigations I found so far is to use Qubes OS with disposable VMs or restricting outbound network, but it's not practical.

My biggest grip with computers always have been "states". What is a state? It is something that distinguish a computer from another: installed software, configuration, data at rest (pictures, documents etc…). We use states because we don't want to lose work, and we want our computers to hold our preferences.

But what if I could go stateless? The best defense against data stealer is to own nothing, so let's go stateless!

2. Going stateless §

My idea is to be able to use any computer around, and be able to use it for productive work, but it should always start fresh: stateless.

A stateless productive workstation obviously has challenges: How would it help with regard to security? How would I manage passwords? How would I work on a file over time? How to achieve this?

I have been able to address each of these questions. I am now using a stateless system.

States? Where we are going, we don't need states! (certainly Doc Brown in a different timeline)

2.1. Data storage §

It is obvious that we need to keep files for most tasks. This setup requires a way to store files on a remote server.

Here are different methods to store files:

• Nextcloud
• Seafile
• NFS / CIFS over VPN
• iSCSI over VPN
• sshfs / webdav mount
• Whatever works for you

Encryption could be done locally with tools like cryfs or gocryptfs, so only encrypted files would be stored on the remote server.

Nextcloud end-to-end encryption should not be used as of April 2024, it is known to be unreliable.

Seafile, a less known alternative to Nextcloud but focused only on file storage, supports end-to-end encryption and is reliable. I chose this one as I had a good experience with it 10 years ago.

Having access to the data storage in a stateless environment comes with an issue: getting the credentials to access the files. Passwords should be handled differently.

2.2. Password management §

When going stateless, the first step that will be required after a boot will be to access the password manager, otherwise one would be locked outside.

The passwords must be reachable from anywhere on Internet, with a passphrase you know and/or hardware token you have (and why not 2FA).

A self-hosted solution is vaultwarden (it used to be named bitwarden_rs), it's an open source reimplementation of Bitwarden server.

Any proprietary service offering password management could work too.

A keepassxc database on a remote storage service for which you know the password could also be used, but it is less practical.

2.3. Security §

The main driving force for this project is to increase my workstation security, I had to think hard about this part.

Going stateless requires a few changes compared to a regular workstation:

• data should be stored on a remote server
• passwords should be stored on a remote server
• a bootable live operating system
• programs to install

This is mostly a paradigm change with pros and cons compared to a regular workstation.

Data and passwords stored in the cloud? This is not really an issue when using end-to-end encryption, this is true as long as the software is trustable and its code is correct.

A bootable live operating system is quite simply to acquire. There is a ton of choice of Linux distributions able to boot from a CD or from USB, and also non Linux live system exist. A bootable USB device could be compromised while a CD is an immutable media, but there are USB devices such as the Kanguru FlashBlu30 with a physical switch to make the device read-only. A USB device could be removed immediately after the boot, making it safe. As for physically protecting the USB device in case you would not trust it anymore, just buy a new USB memory stick and resilver it.

Product page: Kanguru FlashBlu30

As for installed programs, it is fine as long as they are packaged and signed by the distribution, the risks are the same as for a regular workstation.

The system should be more secure than a typical workstation because:

• the system never have access to all data at once, user is supposed to only pick what they will need for a given task
• any malware that would succeed to reach the system would not persist to the next boot

The system would be less secure than a typical workstation because:

• remote servers could be exploited (or offline, not a security issue but…), this is why end-to-end encryption is a must

To circumvent this, I only have the password manager service reachable from the Internet, which then allows me to create a VPN to reach all my other services.

2.4. Ecology §

I think it is a dimension that deserves to be analyzed for such setup. A stateless system requires remote servers to run, and use bandwidth to reinstall programs at each boot. It is less ecological than a regular workstation, but at the same time it may also enforce some kind of rationalization of computer usage because it is a bit less practical.

2.5. State of the art §

Here is a list of setup that already exist which could provide a stateless experience, with support for either a custom configuration or a mechanism to store files (like SSH or GPG keys, but an USB smart card would be better for those):

• NixOS with impermanence, this is an installed OS, but almost everything on disk is volatile
• NixOS live-cd generated from a custom config
• Tails, comes with a mechanism to locally store encrypted files, privacy-oriented, not really what I need
• Alpine with LBU, comes with a mechanism to locally store encrypted files and cache applications
• FuguITA, comes with a mechanism to locally store encrypted files (OpenBSD based)
• Guix live-cd generated from a custom config
• Arch Linux generated live-cd
• Ubuntu live-cd, comes with a mechanism to retrieve files from a partition named "casper-rw"

Otherwise, any live system could just work.

Special bonus to NixOS and Guix generated live-cd as you can choose which software will be in there, in latest version. Similar bonus with Alpine and LBU, packages are always installed from a local cache which mean you can update them.

A live-cd generated a few months ago is certainly not really up to date.

3. My experience §

I decided to go with Alpine with its LBU mechanism, it is not 100% stateless but hit the perfect spot between "I have to bootstrap everything from scratch" and "I can reduce the burden to a minimum".

Earlier blog post: Alpine Linux from RAM but persistent

My setup requires two USB memory stick:

• one with Alpine installer, upgrading to a newer Alpine version only requires me to write the new version on that stick
• a second to store the packages cache and some settings such as the package list and specific changes in /etc (user name, password, services)

While it is not 100% stateless, the files on the second memory stick are just a way to have a working customized Alpine.

This is a pretty cool setup, it boots really fast as all the packages are already in cache on the second memory stick (packages are signed, so it is safe). I made a Firefox profile with settings and extensions, so it is always fresh and ready when I boot.

I decided to go with the following stack, entirely self-hosted:

• Vaultwarden for passwords
• Seafile for data (behind VPN)
• Nextcloud for calendar and contacts (behind VPN)
• Kanboard for task management (behind VPN)
• Linkding for bookmarks (behind VPN)
• WireGuard for VPN

This setup offered me freedom. Now, I can bootstrap into my files and passwords from any computer (a trustable USB memory stick is advisable though!).

I can also boot using any kind of operating system on any on my computer, it became so easy it's refreshing.

I do not make use of dotfiles or stored configurations because I use vanilla settings for most programs, a git repository could be used to fetch all settings quickly though.

Vaultwarden official project website

Seafile official project website

Nextcloud official project website

Kanboard official project website

Linkding official project website

4. Backups §

A tricky part with this setup is to proceed with serious backups. The method will depend on the setup you chose.

With my self-hosted stack, restic makes a daily backup to two remote locations, but I should be able to reach the backup if my services are not available due to a server failure.

If you use proprietary services, it is likely they should handle backups, but it is better not to trust them blindly and checkout all your data on a regular schedule to make a proper backup.

5. Conclusion §

This is an interesting approach to workstations management, I needed to try. I really like how it freed me from worrying about each workstation, they are now all disposable.

I made a mind map for this project, you can view it below, it may be useful to better understand how things articulate.