TL;DR - About switching from Linux Mint to Qubes OS from among various other options that try to provide security out-of-the-box (also discussed: OpenBSD, SculptOS, Ghaf, GrapheneOS)
TL;DR - About switching from Linux Mint to Qubes OS from among various other options that try to provide security out-of-the-box (also discussed: OpenBSD, SculptOS, Ghaf, GrapheneOS)
What I want out of a secure Linux (or BSD) system is full (top-to-bottom) sandboxing of all components to enforce least privilege. I am want to learn how to make my own distro (most likely for personal use) which uses strong SELinux policies, in conjunction with syd-3 sandboxing, which seems like the most robust and feature rich, unprivileged sandbox in both the Linux/BSD worlds (also it’s totally in safe Rust from what i can tell).
Another thing that I would love to make is a drop-in replacement for Flatpak that is backwards compatible but uses syd-3 instead. It has much better exploit protections than Bubblewrap, and is actually an OOTB secure sandbox. I dont know much about the internals of Flatpak, or how to use xdg-desktop-portal, but I am going to start more simple with a Bubblejail alternative. One major advantage of syd is that you can modify an already running sandbox, so theoretical you could show a popup that says something like “App1 is requesting microphone access.”, where you could toggle on without needing to restart the app.
Need to get better at coding tho lol
You can try to just make a hardened NixOS config. The only requirement is systemd to use NixOS options. Other components you can freely interchange.
I’m not very good at securing Linux, but from what I’ve seen, NixOS leaves a lot to be desired. It doesn’t officially support SELinux and requires a lot of work to make it function properly. It supports other mandatory access control programs, which I’m not really sure how they compare. The store being world readable is another problem. The most obvious issue with that is if you’re doing business work with two clients on the same computer where infrastructure needs to remain confidential, where one client’s programs can read the store and see information about the other clients, even on separate user accounts.
I think the preferred approach is AppArmor because SELinux is not supported on immutable distros. I’m not a security expert either, but I would not share environments between two clients at all, I would put them in separate VMs
SELinux is used on all the Fedora Immutable distros, and the OpenSUSE Immutable distro. It’s actually much easier to do SELinux in Immutable distros in a lot of ways than non-immutable. Especially the bootc-style ones where even more of the system is defined and prebuilt before deployment.
AppArmor is OK, but the whole issue is that you have to know what to throw into it. That’s also its benefit, you can focus in the high risk things and ignore the low risk things. It keeps expanding profiles more and more though, and ironically the ultimate destination is everything being under MAC.
Well, that’s because it’s a first party solution. From NixOS point of view SELinux is mutating the store which is forbidden
I’m all for a better Flatpak, but I’m on the fence with full-on usage of Rust, I’d wait for there to be a second Rust compiler. Otherwise, sandboxing might be enough for some users, but not exactly for me.
Rust (Golang or any mem-safe lang) is/are useful for designing secure applications, but not the reason Syd is so great. It is impressive because it is unprivileged, simple yet very granular, has tons of exploit mitigations and hardening options, defaults to hardened_malloc (on arm64 and x64), it’s multilayered sandbox (using landlock, seccomp, namespaces, and more), but of course being written in a memory safe language is an important plus (as memory corruption vulnerabilities are a very large class of common vuln). It abstracts the complexity of working with low-level sandboxing API (such as landlock) while allowing you still construct complicated sandboxes). The dev is also very open to add new ideas.
Syd3, and gvisor, a similar project in go aren’t really sandboxes but instead user mode emulation of the linux kernel. I consider them more secure than virtual machines because code that programs run is not directly executed on your cpu.
Although syd3 doesn’t seem to emulate every syscall, only some, I know rhat gvisor does emulate every syscall.
If you compare CVE’s for gvisor and CVE’s for xen/kvm, you’ll see that they are worlds apart.
Xen has 25 pages: https://app.opencve.io/cve/?vendor=xen
Gvisor has 1: https://app.opencve.io/cve/?q=gvisor
Now, gvisor is a much newer product, but it is still a full 7 years old compared to xen’s 22 years of history. For something that is a third of the age, it has 1/25th of the cve’s.
There is a very real argument to be made that the hardened openbsd kernel, when combined with openbsd’s sandboxing, is more secure than xen, which you brought up.
I could use gvisor inside distrobox inside an appVM in Qubes, couldn’t I?
Many CVE’s for Xen were discovered and patched by the Qubes folks, so that’s a good thing…
As for OpenBSD, I thought I mentioned in the blog post that I’m intending to use it as sys-net VM inside Qubes if not as HVM alongside my Linux appVMs, for when I need Linux. The best of both worlds, so to say.
to answer your first question, kind of. Gvisor (by google btw) uses the linux kernels sandboxing to sandbox the gvisor process itself.
Distrobox also uses the linux kernels sandboxing, which is how linux based containers work.
Due to issues with the attack surface of the linux’s kernels sandboxing components, the ability to create sandboxing or containers inside sandboxes or containers is usually restricted.
What this means is that to use gvisor inside docker/podman (distrobox) you must either loosen the (kinda nonexistent) distrobox sandbox, or you must disable gvisors sandboxing that it applies to itself. You lose the benefit, and you would be better off just using gvisor alone.
It’s complicated, but basically the linux’s kernels containers/sandboxing features can’t really be “stacked”.
Oh, good to know… In other words, sandboxing is not the best practice on Linux… So I’m better off with Qubes than with Secureblue
No, no, no.
It’s no that sandboxing is the best practice, it’s just that attempting to “stack” linux sandboxes is mostly ineffective. If I run kvm inside xen, I get more security. If I run a linux container inside a linux container, I only get the benefit of one layer. But linux sandboxes are good practice.
I do agree that secureblue sucks, but I don’t understand your focus on Qubes. To elaborate on my criticisms let me explain, with a reply to this comment:
If really, really care about security, it’s not enough to “find and patch CVE’s”. The architecture of the software must be organized in such a way that certain classes of vulnerabilities are impossible — so no CVE’s exist in the first place. Having a lack of separation between different privilege levels turns a normal bug into a critical security issue.
Xen having so many CVE’s shows that is has some clear architectural flaws, and that despite technically being a “microkernel”, the isolation between the components is not enough to prevent privilege isolation flaws.
Gvisor having very few CVE’s over it’s lifespan shows it has a better architecture. Same for OpenBSD — despite having a “monolithic” kernel, I would trust openbsd more in many cases (will elaborate later).
Now, let’s talk about threat model. Personally, I don’t really understand your fears in this thread. You visited a site, got literally jumpscared (not even phised), and are now looking at qubes? No actual exploit was done.
You need to understand that the sandboxing that browsers use is one of the most advanced in existence currently. Browser escapes are mostly impossible… mostly.
In addition, you need to know that excluding openbsd, gvisor, and a few other projects almost all other projects will have a regular outpouring of CVE’s at varying rates, depending on how well they are architectured.
Xen is one of those projects. Linux is one of those projects. Your browser is one of those projects. Although I consider Linux a tier below in security, I consider Xen and browsers to exist at a similar tier of security.
What I’m trying to say, is that any organization/entity that is keeping a browser sandbox escape, will most definitely have a Linux privilege escalation vulnerability, and will probably also have a Xen escape and escalation vulnerability.
This is just false. Anybody who is able to do the very difficult task of compromising you through the browser will probably also be able to punch through Xen.
This is true actually. Browser exploits are worth millions or even tens of millions of dollars. And they can only really be used a few times before someone catches them and reports them so that they are patched.
Why would someone spend tens of millions of dollars to compromise you? Do you have information worth millions of dollars on your computer? It’s not a “utopic notion”, it’s being realistic.
If you want maximum browser security,
disable javascriptuse chromium on openbsd. Chromium has slightly stronger sandboxing than firefox, although chromium mostly outputs CVE’s at the same rate as firefox. Where it really shines, is when combined with Openbsd’s sandboxing (or grapheneos’ for phones).Sure, you can run Xen under that setup. But there will be no benefit, you already have a stronger layer in front of Xen.
TLDR: Your entire security setup is only actually as strong as your strongest layer/shield. Adding more layers doesn’t really offer a benefit. But trying to add stronger layers is a waste of your time because you aren’t a target.