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
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.
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
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
It’s not. SELinux predates Fedora. Fedora went all-in on SELinux pretty early on though (a few other older distros too, but Fedora is one of the few remaining with significant mind-share), and many other distros decided not to do security at all for many years.
AppArmor is “sufficient” if you only want to deal with known-in-advance high risk applications being locked down, which was the approach most other distros took since it’s extremely complex to have a policy for absolutely everything (like SELinix requires).
In the latest distros using AppArmor, it’s been expanding so much that it is arguably easier to just implement SELinux and derive from Fedora’s Standard Policy. Ubuntu 24.04 for example was been broken by thier various AppArmor bugs for almost 1.5 years after release, all because they slapped system-wide AppArmor policy restrictions on the default system and didn’t coordinate any of it.
SELinux also doesn’t mutate the store unless the package in the store failed to set an SELinix file label. Providing the labels in most cases is trivial, so trivial in most cases that a global SELinux Nix policy package exists in a number of distros that can set normal defaults that work for most things.
Setting the label is the mutation
And it’s only necessary because Nix doesn’t include it. Which is the only way anything is allowed to run on an SELinux system. SELinux doesn’t require Nix mutation, it requires Nix to be complete.
There are workarounds to fix Nix’s incomplete definitions, but most end users opt for the easy post-install solution that ends up mutating thier store rather than including the fix as a unique derivation for every package to add the missing SElinux labels and policy.