Secureblue: Hardened Immutable Fedora Images
github.com
github.com
> Adds per-network MAC randomization
Where the heck is this thing being used?
> Setting more restrictive file permissions (Based on recommendations from lynis)
Often results in more code being run privileged...
> Brute force protection by locking user accounts for 24 hours after 50 failed login attempts, hardened password encryption and password quality suggestions
Introduces a serious DoS vulnerability.
> Disabling unprivileged user namespaces
> Replacing bubblewrap with bubblewrap-suid so flatpak can be used without unprivileged user namespaces
Trading off possible kernel bugs against letting a whole LOT of userspace software run with real root privilege. And flatpak is a lot of attack surface no matter how you run it, and the packages have a bad security reputation.
> Installing Chromium into the base image (Why chromium?) (Why not flatpak chromium?)
Just more attack surface if you didn't remove Firefox.
> Including a hardened chromium config (disabling JIT javascript)
... and pushing everybody into a less tested code path.
Again, what is this trying to solve?
Security is always a trade off with convenience. Nobody will be installing this distro by accident, so your "who's this for? what is it trying to solve" is a bit misdirected.
With that said - immutable is clearly the future for all operating systems, not just Linux Distros. It doesn't have much to do with security, although that is a side-effect. It mostly has to do with system stability, testability and repeatability.
Ever updated your windows machine and got a BSOD? We all have... immutable means that is very unlikely to happen (because everyone uses the same base OS image), and if it did, rolling back is as easy as rebooting the system.
After you setup your traditional machine, you install various drivers, updates, software, tweak some settings, remove some things - now your environment is unique to only you. This is why complete "base image" testing is impossible with traditional OS'... everyone's is different. Immutable solves that.
Maybe that's clear to you.
> With that said - immutable is clearly the future for all operating systems, not just Linux Distros.
Kind of a side issue. However...
> Ever updated your windows machine and got a BSOD? We all have... immutable means that is very unlikely to happen (because everyone uses the same base OS image), and if it did, rolling back is as easy as rebooting the system.
... until you actually want to use it, at which point you're installing software in some kind of user account or application area, and you get to reexperience all the same problems and reinvent the solutions. Except with an extra layer of complexity to separate the "base image" from whatever you're actually trying to use the computer for.
> This is why complete "base image" testing is impossible with traditional OS'... everyone's is different.
Everyone's actual applications and needs are different.
Sandboxed app environments are easily accomplished today in various ways on Linux and other immutable OS (there's more than you think, including popular mobile operating systems).
The base image never needs to change for any application to be installed and used. Layering is not even a requirement for almost all software to work as expected on an immutable system.
Development is still weird on immutable OS's - since developers do weird things. Currently the solution is pet containers, which are more of a PITA than not, but it does work fine. With that said, modern development environments should not be sprawled all across your system anyway - that's bad for so many reasons.
Regardless, if you would prefer to layer on top of the base os, then you still get the overwhelming majority of immutable benefits.
Immutable is the future...
Why do we not just go to an OS baked into hardware? Because we value updates. The rolling bug-wall that is Linux is a feature, because every OS ever created has holes and flaws and lacks features. It is a nice idea that we could all be on the same system that works flawlessly, but it is not an achievable reality. So while immutable may be the future, it will always be in the future.
As of right now, the system I type this on is updating to "Fedora Kinoite 39.20231215.1". Every single person who has done this same update will be running exactly the same base image, ie. our root filesystems will be identical. Further, the root filesystem was built in a "repeatable/reproducible" way, which means you could go so far as to verify the base image by building it yourself and get an identical output.
This means that base image (read: root filesystem) can be thoroughly tested before it's released. There is no "config drift" with the root filesystem, no drivers/software modifying things in strange ways that might cause unexpected behavior, etc.
In OS-Tree based distributions, you can layer on top of the base image, which creates a new runtime image. Layers can modify the runtime root filesystem, but not the base image's root filesystem! If something breaks, it's as simple as disabling that layer and rebooting, or rolling-back to the previous version. This means in practice it's nearly impossible to actually break your system. You can kind of think of it like "git for operating systems", complete with "git revert" abilities...
The preferred way to install software is via some sort of runtime sandbox, such as Flatpack or similar. This does not modify the root filesystem in any way, and therefore cannot cause an issue at that level. There are additional benefits to running sandboxed applications without access to the root filesystem, such as increased security, but that's a side effect. The main goal is system stability.
I can update entire versions of the OS (say, Fedora 38 -> 39, which I did recently) without any worries my system will be unbootable afterwards. It's not a possibility, barring any hardware issues.
Immutable OS' are a great concept, and will be the future for all "normal" computer users. Many consumer-facing OS' are already immutable, even if they don't advertise as such. These include Android and iOS, ChromeOS and more (with some varying degrees of immutability). These systems are also the least likely to need a wipe/reset once-in-a-while - something Windows users have grown accustomed to.
In fact, it's the exact opposite. It makes it much easier and safer to update because you can immediately roll back to a working version if something breaks.
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...
If you really want to harden an OS with a good SElinux implementation you should try enabling user roles.
Last time I tried that was maybe Fedora 20 something and it broke a lot.
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.
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.
Totally understandable.
an ISO
Small point of correction: we're not publishing ISOs.
I don't understand these spins/release patterns
Most of these several gig ISOs amount to two dozen lines of scripting in the kickstarts
I can't edit now but thought this deserved mention
I am about to rebuild my machine, and have been toying with switching to Qubes or Fedora Silverblue + distrobox, but would love to hear if there are better options available today.
I install so much developer tooling it seems inevitable that a bad actor can slip in and upload my $HOME. Trying to ascertain a practical way of segregating personal data from applications. I already run some apps in VMs, but trying to become a bit more rigorous about isolation.
However, it is definitely not the most privacy-focused OS, due to deep Google integration. This is the main reason that I haven't moved myself over to ChromeOS.
> The following are not in scope for this project:
> Anything related to increasing "privacy", especially when at odds with improving security
> Anything related to "degoogling"
Frankly, knowing nothing further, I'm a little concerned that degoogling would be necessary. Like, is that just because the system bakes in Chromium? How much of the user's privacy is this thing selling away in the name of "security"?
Then most of the changes described are basically reasonable-sounding (very much trading everything else away in the name of security, but fine so long as the user knows what they're doing), but then there's this:
> Disabling unprivileged user namespaces
> 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.
And finally, at a slightly more meta-level: Why should I trust this? It's an unofficial respin by an anonymous user; why would a user trust it?
Having not looked at this project in detail, perhaps it suffers the same fate regardless, but I do find their classification of it as a non-goal to be broadly reassuring.
"Not talking to google" might be more important to some people, and perhaps you're one of those people, so it's good that they're clear about priorities.
Install Kali. There - unless you count Firefox - you have a viable 'degoogled' desktop.
As heuristics go that's how I feel about many "security" respins
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.
Let me rephrase: 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.
But why virtualbox over qemu+kvm? KVM is baked into the kernel, is faster, is supported by vagrant (though not all public vagrant boxes) and has a much better track record of security (even now: Virtualbox disables ASLR).
Technically supported by Vagrant, but every time I tried it was really painful to try and actually use; it's not built-in, so you have to install the plugin which was awful, and then box support was really poor. (To be fair, I ended up dropping Vagrant rather than KVM)
Fedora includes Google components?
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.
And it's also mainly geared towards server use cases, whereas this project is mainly focused on desktop users.