> last I heard it wasn't out of Beta or whatever yet
It is
> But it uses containers rather than VMs
It doesn't use plain containers for app isolation. We ship the OS itself as a bootable container (https://github.com/bootc-dev/bootc). That doesn't mean we use or recommend using containers for application isolation. Container support is actually disabled by default via our selinux policy restricting userns usage (this can be toggled though, of course). Containers on their own don't provide sandboxing. The syscall filtering for them is extremely weak. Flatpak (which sandboxes via bubblewrap: https://github.com/containers/bubblewrap) can be configured to be reasonably good, but we still encourage the use of VMs if needed. We provide one-click tooling for easily installing virt-manager (https://en.wikipedia.org/wiki/Virt-manager) if desired.
In short though, secureblue and Qubes aren't really analogous. We have different goals and target use cases. There is even an open issue on Qubes to add a template to use secureblue as a guest: https://github.com/QubesOS/qubes-issues/issues/9755
I keep hearing different things about how well containers can isolate. I guess the "on their own" caveat is the important one. I don't really know how they work.
Hearing not to rely on it from the developer of secureblue is pretty strong case. Thanks.
We've been working hard to address feedback and make improvements over the last several months. Secureblue now has expanded hardening, improved documentation, and clearer scope.
Trading off possible kernel bugs against letting a whole LOT of userspace software run with real root privilege
Only bubblewrap would run as root, but yes this is a fair critique as this is an opinionated tradeoff. I'm considering adding a set of userns variants to give users the choice between the two.
the packages have a bad security reputation
By default we only enable the flathub-verified remote for this reason.
Just more attack surface if you didn't remove Firefox.
We're removing firefox.
... and pushing everybody into a less tested code path. Again, what is this trying to solve?
No other distro has the same level of immutable tooling or support for immutable variants at this time. Also, Fedora has selinux tooling and enforcing mode out of the box and they're working on further selinux improvements upstream, so we'll get that for free.
I'm a little concerned that degoogling would be necessary.
I don't follow. The readme specifically says it's not in scope.
How much of the user's privacy is this thing selling away in the name of "security"?
Nothing more or less than upstream fedora. The point of putting that in there is to make it so we don't get people opening issues to ask us to switch to Brave or what have you.
tradeoff
Yes, it's a tradeoff and it's made clear in the readme that we're doing this.
Why should I trust this? It's an unofficial respin by an anonymous user; why would a user trust it?
I would have the same question :)
As I said in another comment: All of the CICD is completely open and transparent. You can read through the github actions logs and build config to verify everything for yourself if you want.
What is your distro doing that would make someone want to degoogle it?
Certain users have expressed a preference towards Brave instead of Chromium because in their view Brave's "degoogling" of chromium is preferable. That line is in the readme to clarify that this is not a concern for the project and not in scope.
As a follow up to this, given that bubblewrap-suid without userns vs bubblewrap with userns is a tradeoff, I could make it so both variants are published. This would give users choice between the two and be less opinionated. If this is wanted please open an issue for it and I'll add it.
All of this can be done in several ways. Ansible, manually, a script, etc. Building it into an image just makes it more convenient.
So why should I download images from a 3rd party outside of the Fedora project?
All of the CICD is completely open and transparent. You can read through the github actions logs and build config to verify everything for yourself if you want.
If you really want to harden an OS with a good SElinux implementation you should try enabling user roles.
Agreed, that would be a massive improvement. There's a SIG upstream working on it.
The ublue images are useful to people, so I'm sure your images will be useful to someone. I'm just making a judgement call for myself.
Any other project ontop of Fedora increases the attack vector with its own maintainers.
If I can choose between legible Ansible yaml, and an ISO, I find the yaml much easier to grasp and understand.
Bundling things you could easily do with yaml into an ISO is almost obfuscation. Because most people are not going to read or understand your build config and logs. While Ansible yaml is clearly labeled and tagged for each action.
some corrections:
> last I heard it wasn't out of Beta or whatever yet
It is
> But it uses containers rather than VMs
It doesn't use plain containers for app isolation. We ship the OS itself as a bootable container (https://github.com/bootc-dev/bootc). That doesn't mean we use or recommend using containers for application isolation. Container support is actually disabled by default via our selinux policy restricting userns usage (this can be toggled though, of course). Containers on their own don't provide sandboxing. The syscall filtering for them is extremely weak. Flatpak (which sandboxes via bubblewrap: https://github.com/containers/bubblewrap) can be configured to be reasonably good, but we still encourage the use of VMs if needed. We provide one-click tooling for easily installing virt-manager (https://en.wikipedia.org/wiki/Virt-manager) if desired.
In short though, secureblue and Qubes aren't really analogous. We have different goals and target use cases. There is even an open issue on Qubes to add a template to use secureblue as a guest: https://github.com/QubesOS/qubes-issues/issues/9755