As more devices and systems connect to the internet, cybersecurity has become a core part of our digital infrastructure. The fallout from an attack can reach well beyond stolen data. It can disrupt factories, energy supply, transport networks, and other functions society depends on.
Yet many conventional security tools are built around spotting and handling threats after they have already appeared. What if we designed IT systems differently, so that an attacker has as little room to operate as possible from the very beginning?
That question is the starting point for my project, Boot2Desk: a temporary, security-oriented desktop environment built on Debian 13, developed around the idea of keeping the attack surface as small as possible from the ground up.
Security starts with architecture
One of the central ideas in modern cybersecurity is secure by design: building protection into the architecture of a system rather than bolting it on later.
In practice, that means asking a few basic questions at the outset. Which functions does the system truly need? Which resources should it be allowed to reach? Which communication paths are essential, and which can simply be removed?
Every unnecessary feature, service, or access route is another potential foothold for an attacker. Restricting a system to what it genuinely requires shrinks the attack surface and makes it much harder for a breach to grow into something bigger.
Boot2Desk is built on this philosophy. Rather than taking a traditional operating system and trying to lock down every part of it, I focused on a narrowly defined environment where the security mechanisms are part of the construction itself.
An operating system that forgets on purpose
The most important property of Boot2Desk is that it runs entirely from RAM.
When the computer boots, the operating system is loaded into memory. Everything that changes during the session happens there and is never written permanently to the machine’s internal storage. When the computer is switched off, the session state is gone.
In other words, Boot2Desk has no persistent storage for the session. There is no persistent overlay and no hidden partition quietly keeping the user’s changes between reboots.
Boot2Desk is also designed so that it cannot access or write to the computer’s internal drives, such as SATA, NVMe, and eMMC devices. This lowers the risk of local data being affected and limits the opportunity for malicious code to leave traces on the internal disk.
That makes the system especially interesting in situations where the computer or its physical surroundings cannot be considered fully trustworthy.
Several independent layers of protection
A secure system should never depend on a single safeguard. If one protection is bypassed, the rest of the system should not automatically be exposed. For that reason, Boot2Desk combines several layers of isolation and access control.
- Firejail Runs applications such as Firefox ESR and Remmina in isolated sandboxes.
- AppArmor Limits which resources each process is allowed to reach.
- seccomp Filters the system calls that programs are permitted to make.
- nftables Enforces a firewall that restricts network traffic.
- Wayland and desktop portals Control how applications interact with the desktop and gain access to the user’s resources.
Together, these mechanisms form separate barriers. The goal is that a compromised application cannot automatically reach other programs, perform arbitrary system operations, or move on to more sensitive parts of the system.
Another guiding principle is deny by default: access is refused unless it is explicitly needed. Boot2Desk applies a restrictive firewall policy that blocks incoming connections and limits outgoing traffic.
The aim, then, is not only to detect an attack but to limit what an attacker can actually do when something goes wrong.
No unnecessary services, no unnecessary chatter
Security is also about what a system chooses not to do.
Boot2Desk has no inbound network services, and it has no telemetry, automatic error reporting, or background communication meant to reach outside systems. Keeping the number of active services and communication paths low reduces both the attack surface and the amount of information leaving the machine.
There is a real difference between protecting a system that exposes many functions and building one that exposes only what is absolutely necessary. Every feature removed is one less potential entry point to manage.
From public sources to a verifiable build
Security does not rest on technical features alone. It also rests on trust, and trust grows stronger when people can inspect how a system was actually built.
That is why Boot2Desk is not meant to be a ready-made ISO file that users must trust blindly. Instead, the system can be built locally from public Debian sources using Debian’s live-build tooling.
Configurations, package lists, and security rules are open for review before the image is built, so users can see how the system is put together and run the build themselves.
This model matters because security shouldn’t be something only the developer is able to verify. The easier a system is to review, build, and check, the better the chance of knowing what you are really running.
Where can Boot2Desk make a difference?
A temporary, tightly restricted desktop can help in many situations where the computer cannot be fully trusted. Examples include:
- Consultants handling sensitive information
- Remote access while traveling or on public networks
- Shared workstations and educational environments
- Incident response, where a known clean boot environment matters
It may also be relevant in industrial settings and other organizations with high security requirements, for instance when a computer serves as a limited access point to other systems.
What these cases share is the need to get a job done without leaving unnecessary local data behind, and without giving the user session more privileges than the task requires.
Boot2Desk does not replace the other parts of a complete security effort. Safety is still shaped by the physical environment, user behavior, the design of the network, and the systems you connect to. But by reducing persistent state, restricting access to resources, and isolating applications, several common risks can be reduced already at the design stage.
Making attacks harder from the start
I see Boot2Desk as a practical example of how the principles behind secure by design can be turned into a concrete operating system.
Rather than relying on one security product, the project combines several ideas that work together:
The ideas behind Boot2Desk
- Running entirely from RAM
- No persistent storage
- Restricted access to internal disks
- Isolated applications
- A strict network policy
- A build process that can be reviewed
No single measure can guarantee that a system will never be compromised. But by cutting down the number of possible attack paths and limiting the consequences of an intrusion, we can make it far harder for an attacker to succeed.
Cybersecurity shouldn’t only be about reacting faster once something has happened. It should also be about building systems where as little as possible can go wrong, and where a single failure doesn’t bring the whole thing down.
That is the idea at the heart of Boot2Desk: a computing environment built to do its job, leave as little behind as possible, and start over from a clean state on the next boot.