Title: A Stateless Workstation | |
Author: Solène | |
Date: 20 April 2024 | |
Tags: security linux openbsd unix | |
Description: In this article, I explain the rational and experiment | |
about my project of a stateless workstation | |
# 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! | |
# 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) | |
## 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. | |
## 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. | |
## 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. | |
## 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. | |
## 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. | |
# 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 | |
# 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. | |
# 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. | |
Stateless computing mind mapping document |