The Qubes OS insight is correct. The implementation is wrong.
Security through compartmentalization is the right idea. Run your browser in one box, your email in another, your documents in a a compromise in one cannot spread to the others. Qubes OS proved this model works.
But Qubes OS pays for that isolation with a hypervisor, multi-gigabyte VM images, separate kernels, and a GUI stack that adds tens of millions of lines of code. The baseline is 8 GB of RAM and an install that takes hours. The attack surface grows with every layer. Complexity is not just complexity is the vulnerability. At a conservative defect rate of 0.1%, a codebase of 100 million lines ships with 100,000 bugs. Some of them are exploitable. You don't know which ones.
dropQbsd takes the same insight and strips away the hypervisor.
Instead of virtual machines, it uses the native user separation built into the only operating system on earth that undergoes continuous, funded, line-by-line security auditing. No Xen. No multi-gigabyte images. No moving parts you cannot audit in an afternoon.
The Architecture
Four users. One kernel. Zero telemetry.
| User | Role | Network |
|---|---|---|
user | orchestrates, imports/exports | Updates only |
userweb | We isolated from mail and LAN | HTTP/HTTPS only |
usermail | Email isolated from web | Mail servers only |
userdoc | Documents, sync, LAN storage | LAN + Syncthing |
Home directories are `chmod 700`. Cross-domain snooping is impossible at the filesystem level.
A single shared the *drop is the only bridge between domains. Files in transit are locked to 440 (read-only). No domain can delete another domain's files. No domain can modify files once placed. A cron job enforces these invariants every 60 seconds, quarantining violations with an audit ticket. There is no ambient trust.
The Blind Gate
The hardest problem in this model is launching graphical applications across user boundaries without handing user a root shell. The standard sudo, doas, all expand the attack surface. Every conditional, every configuration parser, every error handler is a potential path to privilege escalation.
dropQbsd solves this with a three-file split:
| File | Type | Role |
|---|---|---|
run_app | Compiled binary (setuid root) | 10 lines of C. No logic. No parsing. No branching. |
run_app_impl | ksh script | All the domain selection, X11 cookie handling, tmpfs setup |
run_app_wrapper.c | C source | Reference only; not needed at runtime |
run_app does exactly one thing: setuid(0), then execv into run_app_impl. It is the *blind immutable after compilation, frozen at 10 lines, incapable of doing anything except calling the script. If you need to add a domain, change paths, or adjust cleanup behavior, you edit run_app_impl. No recompilation. The attack surface stays frozen.
doas.conf contains exactly one line: permit nopass root. The user account has no doas access whatsoever. The only path to root is through the blind gate, and the blind gate can only launch domain applications.
Network Isolation
pf.conf enforces a default-deny policy with per-domain rules:
userwebreaches ports 80/443 only. RFC 1918 addresses are explicitly no LAN pivoting, no localhost access.usermailreaches only IPs in the<mailserver>table, only on mail ports.userdocreaches LAN subnets and Syncthing ports only.- Root has no permanent network only IPs in the
<updates>table, populated on-demand.
Service IPs are managed via dynamic PF tables fed from /etc/tables/. No provider details are exposed in the repository. Root phones home to nobody.
Disposable Browsers
run_app supports a --disposable flag. When set, the target domain's home directory is mounted as a tmpfs in RAM. When the browser exits, the tmpfs is unmounted. Nothing survives. No persistent cookies, no cached credentials, no lingering exploit payloads.
$ run_app --disposable userweb qutebrowser --temp-basedir
$ run_app --disposable 1G userweb chromium https://example.com
A compromised browser is evicted at session end. The attacker starts from zero next time.
The Tradeoff
dropQbsd is not Qubes OS. It makes a deliberate trade: kernel isolation and input isolation for simplicity, auditability, and a 512 MB RAM baseline.
| dropQbsd | Qubes OS | |
|---|---|---|
| Isolation mechanism | Unix users + permissions | Xen hypervisor + VMs |
| RAM baseline | 512 MB | 8 GB |
| Input isolation | None (shared X11 cookie) | Full (separate X servers) |
| Kernel isolation | None (shared kernel) | Full (separate VM kernels) |
| Disk usage | ~2 GB | 30+ GB |
| Install time | 10 minutes | 2 hours |
| Rebuild from scratch | 30 minutes | Hours/days |
| Code to audit | ~500 lines of ksh + 10 lines of C | Millions of lines |
X11 input isolation is the most significant limitation. A compromised domain with access to the X11 cookie can keylog other domains. Mitigations include per-session cookies via xenodm, XTEST disabled where possible, and disposable tmpfs browsers that limit the window of compromise. But this is a fundamental X11 limitation, not a dropQbsd bug. If your threat model includes targeted input sniffing, Qubes OS is the correct choice.
Conductor compromise is the other hard boundary. If user is via a malicious file or a local all domains fall, because user holds the keys to run_app. The mitigation is procedural: keep user minimal, inspect files before importing, never run untrusted binaries there.
Kernel-level attacks cross all domains because all domains share one kernel. This is the price of avoiding virtualization. If your adversary has kernel exploits, you need Qubes.
Why OpenBSD
Linux distributions ship with systemd, pulseaudio, dbus, and millions of lines of code that nobody has audited end-to-end. They phone home through package managers, crash reporters, and "telemetry" that gets enabled by default in increasingly many distros.
OpenBSD ships with zero telemetry. Its codebase is small enough to be understood by a single developer. It undergoes continuous, funded, line-by-line security not as a marketing claim, but as an engineering process that has produced exactly two remote holes in the default install in over twenty-five years.
Security is simplicity. Privacy is auditable. OpenBSD is the only operating system that delivers both as a matter of engineering discipline, not marketing copy.
What dropQbsd Protects Against
- Malware propagation between domains. A compromised browser cannot read your email or reach your documents.
- Network pivoting. A compromised web domain cannot reach your mail server or LAN.
- Persistent browser compromise. Disposable tmpfs profiles evict the attacker at session end.
- Accidental data leakage. The drop zone is policed every 60 seconds. No file moves without enforcement.
- Silent policy violations. Quarantine catches and explains every non-conforming file.
- Privilege escalation via sudo/doas.
userhas nodoasaccess. The blind gate cannot be subverted into a general-purpose root shell.
The Real Argument
dropQbsd is not a product. It is a demonstration that compartmentalization does not require a hypervisor, privacy by design does not require a budget, and security does not require millions of lines of code.
Ten minutes to install. Rebuildable in thirty. Zero lock-in.
Repository: https://github.com/nobraininside/dropQbsd/