Last month I read Solene's article -- A Stateless Workstation -- regarding her live experiment with a stateless workstation, where she basically describes a Linux-based system, mostly deployed in a read-only manner, apart from a few folders that hold the user state, namely documents and application data.
Sidenote
I shall use the expression "read-only distribution" or "read-only system" instead of the current trending term of "immutable distribution".
This is because technically an "immutable distribution", as it is described today by its proponents, isn't strictly read-only (thus immutable) with regard to the file-system, but instead it's closer to the A/B partition style of managing updates in the embedded world, but instead of using different partitions, current "immutable distributions" use file-system based techniques such as snapshots.
In fact, even Solene says that most current immutable distributions "don't bring much to the security table".
Back to Solene's story, her main threat model is mainly comprised of backdoored kernel, services, or user applications that persist across boot and go unnoticed for long periods of time. In such a case, the backdoored malware can snoop on the keyboard, exfiltrate (or even ransom, destroy, or worse, forge) documents or other sensitive data; intercept (and even counterfeit) network communications (be they wireless or wired), leverage SSH credentials (including unprotected SSH private keys) to infect other machines one has access to, and many more types of attacks we don't know of yet. (Needless to add, I completely agree with her assessment, especially since I share the same concerns.)
Sidenote
And lately, the backdoor can even be embedded as low as at the UEFI firmware level, thus bypassing the Secure Boot promises, because not only do you have to trust the entire chain of execution, you have to also trust each stage of the chain.
For reference, see one of these articles:
The solution Solene proposes, as hinted earlier, is a stateless and read-only Linux-based system, with all the user state stored on a separate partition (or even a USB stick if one desires portability); for more details, read Solene's original article: A Stateless Workstation.
Although the proposal does solve a few of the stated problems, I would say it doesn't go far enough.
For example, if one uses a live-CD or in-memory system, where all the service and application files are loaded into memory or swap (or even hosted on physically read-only media like the CD), and thus the initial boot media can't be compromised (at each boot one gets a pristine, uncompromised system), there is still the possibility of service or application compromise (for example through RCE, remote code execution, or other vulnerabilities) during the current execution session that would, fortunately, last only until the next boot.
During this time window, from a security point of view, there is no difference between a traditional OS deployment (persistently installed on read-write media, such as a disk or solid state) and a stateless one (providing a pristine and uncompromised system on each boot). The compromised service or application can still do whatever it wants, like exfiltrating or destroying documents or data, snooping on the keyboard and network, etc.
Therefore, besides moving to a read-only OS deployment and moving to a cloud-based document and office solution (including self-hosted), as Solene proposes in her article, a few other steps could be taken to reduce the access a compromised service or application has to the user's documents and data.
Sidenote
Last October, while listening to one of the Late Night Linux family of podcasts, one of the hosts mentioned that one of the Raspberry Pi Zero's can act as a USB device, thus when plugged into a laptop / desktop (which has the role of USB host), it would then present itself as a USB network device (or keyboard, serial, storage, etc., as supported by the Linux USB Gadget family of kernel modules).
Thus, the small Raspberry Pi Zero, being seen as a network device by the laptop / desktop, would allow point-to-point networking (from a physical point of view, not the underlying networking protocol, which is still Ethernet), reducing the external snooping potential to only the physical USB link between the two.
This blew my mind!
For a few years now, I thought of ways to have a practical "secure enclave" (practical being the highlight here) running critical services, or holding sensitive data, and now I have a practical lead on a solution.
Back to Solene's stateless solution, what if:
instead of using SSH keys (I don't even take into account SSH passwords) stored on the local computer (i.e. our laptop / desktop running the read-only OS), we move to an SSH-agent running on the "secure" computer (i.e. the Raspberry Pi Zero in my case), which is forwarded over a secure connection from the "secure" computer to the local one (for example via SSH);
instead of requiring external cloud-based services for documents, notes, office, password management, etc., we keep using our classical desktop-based applications, but access our documents and data over the network (from the "secure" computer) via a protocol like SSH/SFTP (mounted via the venerable FUSE-based SSHFS), or even something like NFS or CIFS (i.e. Samba) shares;
alternatively, instead of the same cloud-based services, we could even deploy self-hosted alternatives on the "secure" computer; (although this would widen the attack surface of the "secure" computer;)
Thus, even if the attacker is able to compromise the local laptop / desktop, that wouldn't be enough to get to our sensitive data, and would require lateral movement to the "secure" computer.
Sidenote
I keep using "secure" computer, as in quotes secure quotes, because it's not absolutely secure, it's just a bit more secure than the local device.
Sure, the attacker could try to exfiltrate or overwrite the documents and data the compromised laptop / desktop applications have access to, but this action could be mitigated on the "secure" computer by various means.
For example, rate-limiting access, and / or requesting TOTP-like authentication (once in a while, or when limits are reached), one could limit the amount of exfiltrated data. Then, having constant backups or snapshots (running on the "secure" computer) one could mitigate the destruction or ransomware atempts. I bet many other clever solutions could be found to mitigate many potential problems once the "usage" of the data (i.e. the laptop / desktop) is separated from the "storage" of the data (i.e. the "secure" computer).
As a final note, this is not a silver bullet for all security problems.
If the "secure" computer runs a vulnerable, and network accessible service, then lateral movement by the attacker can be achieved, and thus compromising the "secure" computer doesn't get us in a better situation than before.
Sidenote
And here I have to acknowledge one of the latest OpenSSH vulnerabilities, "regreSSHion", as described in regreSSHion: Remote Unauthenticated Code Execution Vulnerability in OpenSSH server, that basically grants anyone with network access (or in our case with access to the laptop / desktop that the "secure" computer is connected to), RCE (remote code execution) on the target, thus rendering the "secure" computer less so "secure"...
However, this is a layered security approach, also called defense in depth:
- first, the attacker has to compromise one's laptop / desktop;
- then the attacker has to compromise the "secure" computer;
By minimizing the attack surface of the "secure" computer, we minimize the chance the attacker can gain full access to our sensitive documents and data.
Sidenote
BTW, I've been working on implementing something similar to the above "secure" computer, that runs on a Raspberry Pi Zero 2 W (connected via USB to the laptop / desktop), or any ARM64 or X86-64 compliant system that has a network port (and thus, connected via Ethernet to the laptop / desktop).
The Linux-based minimal OS is kind of working, but the software layer is yet to be developed.