secureblue

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

Instructions are of course in the readme! :) https://github.com/secureblue/secureblue

And it's also mainly geared towards server use cases, whereas this project is mainly focused on desktop users.

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.

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?

Around half of V8 vulnerabilities are enabled by JIT: https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...

Totally understandable.

an ISO

Small point of correction: we're not publishing ISOs.

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 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.

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.