Secureblue: Hardened Immutable Fedora Images
github.comNo threat model given.
> 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?
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...
One of the targeted user-groups is clearly people who travel a lot and are on various untrusted networks often (airports, coffee shops, hotels, etc).
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.
> One of the targeted user-groups is clearly people who travel a lot and are on various untrusted networks often (airports, coffee shops, hotels, etc).
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.
For everyday usage, like surfing the internet, word processing, emails, gaming, etc - these are all non-issues.
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...
Even hardware layer is not truly immutable, but lets say that it is. Having another immutable layer (ie secureblue) on top means less flexibility to interact with the hardware layer, and the requirement of putting another layer under the immutable software layer (eg the sanboxed OS one actually wants to use.
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.
Immutable = no updates is just a complete misunderstanding of what an immutable OS is.
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.
Immutable does not mean "no updates". Immutable means you and I both are running the same base image, given we are running the same version of base image.
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.
FYI, both userns and non-userns variants are now available. https://github.com/secureblue/secureblue/commit/38999d4123aa...
Most of this can be done with Ansible. So why should I download images from a 3rd party outside of the Fedora project?
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.
Most of this can be done with Ansible.
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.
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.
I see this (and other ublue images) as an alternative to Ansible, rather than just an image. I could fork this repo, automate PRs from upstream with a GH action while making my own changes to it and keep an automated CI/CD pipeline. This painless extensibility is a big advantage imo over traditional distributions.
Heck, all of this can be done with the installer - Anaconda, with kickstart.
I don't understand these spins/release patterns
Most of these several gig ISOs amount to two dozen lines of scripting in the kickstarts
note: I realize this release takes advantage of OSTree - that's pretty solid. Flipping an installation to another is clever.
I can't edit now but thought this deserved mention
What is considered the most security conscious OS today? What is the most secure OS that can be run without enormous pain?
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.
Ironically, ChromeOS is likely the most security-conscious OS available for developers. See: https://news.ycombinator.com/item?id=37783081
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.
As mentioned, Qubes would be ideal for this. A new VM for each development project (or same attack levels - for example, VM for professional software dev, VM for side projects, VM for playing around with random interesting GH projects, etc). Requires a ton of RAM though - also a good CPU. And forget about gaming!
An SEL4 kernel based os, but they’re few and far between for desktop use for some reason.
If only NixOS supported isolating packages/devshells
This is awesome. Hardened_malloc and JITless Chromium OOTB. It's hard to find hardened desktop linux distro, this might be it.
So I'm not against it in the general case, but there are some very specific tradeoffs being made here.
> 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?
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.
> I don't follow. The readme specifically says it's not in scope.
Let me rephrase: What is your distro doing that would make someone want to degoogle it?
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.
If that's what you mean, I would strongly suggest just saying that in the readme
Just changed it. Thanks for the feedback!
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.
"degoogling" is nice in theory but I've rarely seen it done well in practice. There are either severe UX tradeoffs, or security pitfalls where maintainers mess with configs they don't actually understand.
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.
> "degoogling" is nice in theory but I've rarely seen it done well in practice. There are either severe UX tradeoffs, or security pitfalls where maintainers mess with configs they don't actually understand.
As heuristics go that's how I feel about many "security" respins
> "degoogling" is nice in theory but I've rarely seen it done well in practice.
Install Kali. There - unless you count Firefox - you have a viable 'degoogled' desktop.
I think there are some default libraries that support using Google Drive for backups, calendar, and email, among other things? TBH, I'd be surprised if those were in scope.
When I would use an Immutable Linux I would not be able to run Virtualbox right? Because that needs kernel modules loaded and changes to the core system that is immutable or do I get this wrong?
Immutable is more about the root filesystem not letting you alter it easily; if the modules are included and not blacklisted (this project talks about blacklisting uncommon modules; I haven't looked at the list) there's no reason it wouldn't work fine.
immutable means read-only; so if you repackage the OS to have virtualbox in the base image then it would work, theoretically.
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).
> 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)
> Anything related to "degoogling"
Fedora includes Google components?
Some people think that Brave is preferable to Chromium because they "degoogle" it.
Ah, so it's just Chromium. Thanks.
Is fedora the best OS to be using as a baseline for security?
It's pretty good, they're fairly aggressive with C build tool chain security stuff.
Are you not concerned that maybe some of it’s more bleeding edge features are not battle tested?
Oh Fedora definitely battle-tests them. RHEL does too.
Could you please explain the thought process that led you to settle on Fedora? Thanks!
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.
opensuse..tumbleweed..transactional server
Clearlinux?
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.