secureblue
Joined 2 years ago
Karma
89
Submissions
18
Member since
Dec 15
Recent submissions
Comment · 1 year ago
Comment · 2 years ago
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.
Instructions are of course in the readme! :) https://github.com/secureblue/secureblue
Comment · 2 years ago
FYI, both userns and non-userns variants are now available. https://github.com/secureblue/secureblue/commit/38999d4123aa...
Comment · 2 years ago
Clearlinux has nothing comparable to this as far as I know: https://github.com/ublue-os/startingpoint
And it's also mainly geared towards server use cases, whereas this project is mainly focused on desktop users.
Comment · 2 years ago
Just changed it. Thanks for the feedback!
Comment · 2 years ago
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.
Comment · 2 years ago
Some people think that Brave is preferable to Chromium because they "degoogle" it.
Comment · 2 years ago
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?
Around half of V8 vulnerabilities are enabled by JIT: https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...
Comment · 2 years ago
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.
Comment · 2 years ago
I'm just making a judgement call for myself. Any other project ontop of Fedora increases the attack vector with its own maintainers.
Totally understandable.
an ISO
Small point of correction: we're not publishing ISOs.
Comment · 2 years ago
Universal blue, the starting point for this project, is fedora based. https://universal-blue.org/
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.
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