The secureblue project is a set of changes applied to the Fedora Silverblue/Kinoite project in an attempt to secure it as much as possible without sacrificing usability. It can be easily applied with just a few commands using rpm-ostree to rebase the system.
It’s worth discussing the value of mentioning this project for users of Silverblue/Kinoite. However, there are a few caveats usability-wise, such as issues with using GrapheneOS’s hardened_malloc for certain flatpaks such as Thunderbird. Albeit, the user can solve this particular issue by using flatseal to disable hardened_malloc for troublesome flatpaks such as Thunderbird. It’s also worth noting that some of secureblue’s choices could lead to worse privacy, such as the removal of Fedora’s default Firefox in place of a hardened yet fully Googled Chromium.
I’d love to hear the thoughts of the community regarding this project.
This project is on my radar, I was initially fairly excited about it, I think its worth paying some attention to, but I think it is too new (just over a month old), too unknown, too unproven to be considered for recommendation at this point. The project is just over a month old as best I can tell. I spoke with the creator of this image very briefly a few weeks ago and was mildly uneasy with some of the answers they gave which at least in one case contradicted each other with conflicting absolutist statements, and made me feel that maybe not a lot of thought or consideration had been given to some of the choices they made, or their opinions change frequently and rapidly.
For example,
when asked about the decision to use Chromium instead of Brave, despite them having used Brave in their last project they said:
Brave offers no security improvements while adding additional attack surface. There is no reason whatsoever from a security perspective to use Brave over a properly-built Chromium.
Despite the fact that just 3 months earlier they specifically chose to use Brave over Chromium for an earlier security focused fedora project (the predecessor to the secureblue image). With the earlier project, this is how they explained the choice to use Brave:
We Install Brave Browser and its rpm repo:
(Unfortunately, the Fedora Chromium rpm is consistently behind security patches, so Brave provides an up-to-date Chromium-based browser. Brave also has content blocking built-in, avoiding the need for MV2 extensions)
They did go on to explain the change in thinking when asked directly to explain the change, but to me, the absolutism of their statement that "There is no reason whatsoever from a security perspective to use Brave over a properly-built Chromium"* despite them having literally just used Brave instead of Chromium in a security project a few months earlier, without at least acknowledging their change in thinking, implies to me a potential erraticness or lack of stability and seriousness of the project/developer of the project. I believe nobody should be judged based on just a few isolated statements, but it was a ‘yellow flag’ to me, that somewhat cooled my enthusiasm towards the project. I am still interested in it, but not yet ready to put trust in it.
I think if the project is around and actively maintained in a year, and has proven itself as somewhat reliable, secure, consistent, it may be worth consideration. But at this point its too early to recommend with any confidence. That said, I think looking into it and discussing it here would be constructive. I’m especially interested in what @SkewedZeppelin might have to say, as I know they also have experience with Hardening Fedora.
I briefly covered it in my chat a month or so ago and largely found it hacky/haphazard compared to my Brace or the even better documented Kicksecure project.
Maybe worth checking back in a few months.
Brief unformatted copy/paste, and please note that they’ve hopefully fixed some of this since then:
- removes firefox
- installs chkrootkit!?
- and some other junk like vscode
- focus on nvidia
- disables smt
- doesn’t enable spectre mitigations on userspace
- removes printing support
- removes useful accessibility features
- installs a bunch of fonts
- I did this 10 days before: Fix wireplumber issue with hardened malloc #92 · ublue-os/startingpoint@25ac909 · GitHub
- inferior to my package and buries the credit for rusty-snake: fedora-extras/hardened_malloc/hardened_malloc.spec at d8948b7021270644d5a85158bc9ab4f086dec406 · qoijjj/fedora-extras · GitHub
- this is the wrong way to disable the jit: Hardened chromium config · ublue-os/startingpoint@a3ddde9 · GitHub
- they’re not even crediting other things they copied:
- even their chromium is outdated? https://github.com/qoijjj/chromium-rpm
HN discussion
Interesting. As an user of fedora workstation I’m going to keep an eye on this one.
There were some interesting points raised in that which I’m inclined to agree with:
Most of this can be done with Ansible. So why should I download images from a 3rd party outside of the Fedora project?
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.
Replacing bubblewrap with bubblewrap-suid so flatpak can be used without unprivileged user namespaces
And that’s… again, I’m not going to say wrong, but it’s a very specific tradeoff to decide that you trust bubblewrap more than the kernel. It’s a plausibly-sensible trade, given the relative number of CVEs in bubblewrap with suid and linux’s unprivileged user namespaces, but I’m not sure it sits well with me.
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.
Why should I trust this? It’s an unofficial respin by an anonymous user; why would a user trust it?
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.
At this point I’m not sure what it benefits over Ansible. If I have to audit their CI system I think it would be easier to just audit a YAML script used with Ansible.
while I agree with most the points you bring up, I just have to correct:
- focus on nvidia
uBlue images come in “main” (FOSS/mesa) variants and “nvidia” (proprietary) variants. Secureblue has no focus on nvidia AFAICT
The few overall benefits I have noticed with this project is that it incorporates hardened_malloc, the memory allocator known from GrapheneOS.
Some of the other changes to Fedora immutable could be done by the user without rebasing on Secureblue; such as removing the Fedora Flatpak repository and replacing it with Flathub Verified (user).
Disabling JIT can also now be done in any Chromium-based browser, with the additional benefit of being able to disable it per-site; Secureblue requires you to manually create a Chromium policy to do this, and disables the toggle in Chromium’s settings.
The claim that Brave adds additional attack surface by piling on features is probably accurate.
Edit: the developer has now provided an explanation to this.
But the contradictory statement of preferring Fedora’s package for Chromium after claiming that it’s lagging behind on security patches is confusing and would preferably need to be explained further. On that note, when I tried out Secureblue yesterday, the Chromium version was fully up-to-date with version 122. Have not been able to observe how regularly they are released in practice, however.
Hi folks, I’m the maintainer and creator of the secureblue project, and stumbled across this thread. There is an overwhelming amount of misinformation in here, so I figured I would address it piece by piece:
- removes firefox
We document thoroughly why this is done. Firefox’s security features are lackluster compared to Chromium’s when built properly.
- and some other junk like vscode
No longer done
- focus on nvidia
Not accurate, we have generic images and images for all kinds of hardware
- disables smt
Yes, we set auto,nosmt for kernel mitigations. This disables smt if the CPU is vulnerable to smt attacks. Saying that our project is “haphazard” while objecting to an entirely reasonable change is rich.
- doesn’t enable spectre mitigations on userspace
Not accurate
- removes printing support
Yes and the user can reenable it if they choose
- removes useful accessibility features
Not accurate
- installs a bunch of fonts
Not accurate and not a problem even if it was
they’re not even crediting other things they copied:
Daniel Micay has looked at the project and didn’t take objection to this in our discussions. I can add a note that this is from GrapheneOS if the GrapheneOS team asks me, but they don’t seem to care.
- even their chromium is outdated? https://github.com/qoijjj/chromium-rpm
Inaccurate again. This was never our chromium. We use the Fedora chromium rpm and submit changes upstream if needed. This was a personal testing repo that never even built correctly 
Despite the fact that just 3 months earlier they specifically chose to use Brave over Chromium
Yes, and for a clear reason. At that time the chromium rpm was not being consistently updated, so there was a reason not to use it. Brave served a purpose at that time. Now, chromium is consistently updated and is built properly. There is no contradiction between our earlier use of Brave and the statement: "There is no reason whatsoever from a security perspective to use Brave over a properly-built Chromium"
Properly-built means up-to-date and with the correct build flags set.
And that’s… again, I’m not going to say wrong, but it’s a very specific tradeoff to decide that you trust bubblewrap more than the kernel. It’s a plausibly-sensible trade, given the relative number of CVEs in bubblewrap with suid and linux’s unprivileged user namespaces, but I’m not sure it sits well with me.
We build both image types now, so it’s up to the user.
At this point I’m not sure what it benefits over Ansible. If I have to audit their CI system I think it would be easier to just audit a YAML script used with Ansible.
This is a reasonable critique, the only benefit is convenience over ansible. But at the same time, our whole repo is really small, you could read through it in the same amount of time as a repo of ansible files. Our repo is mostly yaml anyhow.
contradictory statement of preferring Fedora’s package for Chromium after claiming that it’s lagging behind on security patches is confusing and would preferably need to be explained further.
There’s no contradiction. It was lagging on security patches, but it is no longer. I talked to the Fedora maintainers about, among other things, improving the build cadence.
Hopefully that clears up a lot of the concerns and misconceptions
fwiw my original post was written nearly 4 months ago and a lot has clearly changed (which is good!), but for the record:
Was accurate, packages like yelp and ibus-typing-booster were removed:
No longer done would be more accurate: secureblue/config/recipe-silverblue-main.yml at cb11fbcaaed34c92d0993fb1f4395824f28d3742 · secureblue/secureblue · GitHub
It is still accurate, you need to explicitly set spectre_v2=on for this to happen.
Selecting ‘on’ will also enable the mitigation against user space to user space task attacks.
You should also consider adding ia32_emulation=false, especially for the benefit of the hardened_malloc.
But you might want to add some special handling for this as eg. dracut will generate broken initramfs images if any *.i686 packages are installed.
re: credit, I pointed out 3 different things there, not just one.
anyway, not going to argue, and I think we need more projects like yours around
p.s. I’d love to see a project like yours ship fapolicyd in production, would be cool!
Was accurate
Yes, from before this was a public project and was a personal image repo.
you need to explicitly set spectre_v2=on
That is not correct. From the document you linked:
auto
kernel detects whether your CPU model is vulnerable
Not specifying this option is equivalent to spectre_v2=auto.
Same goes for spectre_v2_user:
Not specifying this option is equivalent to spectre_v2_user=auto.
auto - Kernel selects the mitigation depending on the available CPU features and vulnerability.
Leaving both unset lets the kernel determine what’s necessary for both spectre_v2 and spectre_v2_user
re: credit, I pointed out 3 different things there, not just one.
I only see two, and the other one is RustySnake’s hardened_malloc rpm spec which I forked and modified. No credit was hidden…
You should also consider adding ia32_emulation=false, especially for the benefit of the hardened_malloc.
But you might want to add some special handling for this as eg. dracut will generate broken initramfs images if any *.i686 packages are installed.
Yeah I need to look into this again. If there’s a way to do it without breakage it would be a good addition.
anyway, not going to argue, and I think we need more projects like yours around
Appreciate it and your project Brace as well, I hope I gave sufficient attribution in our chromium policy file 
let me know if not.
re: spectre_v2
by default (auto) it only protects the kernel against userspace.
it will only protect userspace against userspace when set on.
they deemed the performance cost too high to enable under auto.
you can confirm this from the dmesg output
if it says User space: Mitigation: STIBP via seccomp and prctl that means only if a program opts-in or is using seccomp will it protect that process
only when it says User space: Mitigation: STIBP always-on protection is it actually protecting userspace to userspace
I see. are you referring to this line?
Selecting ‘on’ will also enable the mitigation against user space to user space task attacks.
If the behavior is like you describe, it is not captured well in the kernel docs.
they deemed the performance cost too high to enable under auto.
Do you have an lkml thread on this? If what you’re describing is accurate I’ll make the change, but it would mean the kernel docs are misleading.
Added some additional attributions here. add additional attribution to the readme · secureblue/secureblue@c29636f · GitHub
If as you mentioned you also have recommendations for our hardened_malloc spec, I’m happy to make improvements.
One other note I forgot to mention is that sadly, Kicksecure is inexplicably dropping hardened_malloc
You are right though it is much better documented.
Edit: since I’m a new user I’m not permitted to post more than three times in a topic. I’m reachable via github issues or the discord linked in github issues if there are further questions:
Hello, could you guys help with a couple of questions for curiosity and general understanding? I am Silverblue user, sometimes I switch to next release early, sometimes wait till released (like 39 killed most extensions, no need to rush for update). If I decide to trust one man show project, like Secureblue can I rebase to Secureblue 40 early or only after release? Maybe even later, it would not be available same day, as Silverblue 40?
why do you use proprietary walled garden discord? dont tell me its for security, thatd give me a good laugh
Using tlp in the laptop images seems to be a bad idea. According to tlp’s docs, since Fedora 38, tlp is broken. Have you tested if it’s working as intended? As of december '23, the tlp dev maintains that the Fedora package lacks key functionality.
On a related note, ublue has deprecated the Framework images which also implement tlp.
I’m using tlp right now, yes.
However you are correct that, TLP and the framework images are no longer needed, dramatically shrinking our image matrix. This deprecation will be coming in the next week or so
one man show
I’m the primary contributor but not the sole contributor. Also, the entire repo is very small and easy to maintain, you can read through the whole thing in less than ten minutes.
Maybe even later, it would not be available same day, as Silverblue 40?
Fedora 40 images will be available on the same day that uBlue releases Fedora 40 images, which is usually a few weeks before the actual Fedora 40 release.