The secureblue project has done a lot of testing, following a "if it may be insecure or we dont know how to fix it, we turn it off" approach.
This results in an often worse UX, but the benefits are there.
Big issues are especially
- removals of base packages, which cannot be layered again, due to how OCI container builds work
- firewall rules being all removed, making some things hard to get working again
A ton of other issues where ironed out already.
kernel arguments
For example the kargs, included in their just file.
I discovered a bug back then on my crappy Lenovo Thinkpad firmware, so some are called "unstable" (they are not unstable, they simply break boot on some strange proprietary firmware). I run 3 coreboot laptops (EDK2, Heads, Dasharo) all with those "unstable" kargs without issues.
disabling/enabling CUPS on demand
This is always a good measurement.
hardened_malloc
This is a security hardened memory allocator, forked by GrapheneOS developers from the OpenBSD project. It works really fine on Desktop linux too. Chromium works, desktops and apps all work.
using hardened_malloc has some drawbacks, mainly:
- the implementation is not clean, normally you would need to recompile glibc with hardend_malloc afaik. Instead, secureblue just preloads it with LD_PRELOAD
- firefox uses it's own memory allocator "mozjemalloc" which results in a crash when using hardened_malloc with LD_PRELOAD. For that reason, Fedora Firefox allows using different mallocs and I tested it and it works. Torbrowser devs thought about it, not sure about the progress in Librewolf, may be done too.
- Electron apps dont use hardened_malloc because they do some magic
- flatpak apps need a whole in their sandbox to read that library. otherwise, a flatpak runtime extension would be needed, which doesnt yet exist
- the LD_PRELOAD method may just not break the system as many components dont respect it.
- when recompiling core components for hardened_malloc, you dont have a fallback, like you have in GrapheneOS (where you can disabled hardened_malloc per app)
removal of insecure remote desktop apps
KRFP (VNC) is an example, it supposedly works but is unencrypted?
Instead, KRDP (RDP) can be used, but RDP requires nonfree codecs like h264 afaik.
Not sure about GNOME.
This is a pre-release application, more or less experimental. It is built on COPR using this or this spec file.
Background, Browser Sandboxes
Flatpak has some issues, like the generalized but restrictive seccomp filter on all apps.
That filter prevents apps from creating their own user namespaces, meaning browsers cannot normally work.
Chromium uses a fork server called "zygote" which can be tricked to use "flatpak spawn" instead, so Chromium browsers kinda work. The security of that process is unclear, it may not be well enough restricted (especially comparing the amounts of money flowing into bubblewrap vs. the Chromium process Sandbox) but in theory it can be better, as the browser itself is sandboxed too.
Firefox... has no fork server, so it cannot use this approach. The Flatpak is insecure and simply doesnt use any filesystem sandboxing with namespaces at all. Instead it just uses seccomp-bpf and that is it.
This means, Firefox should not be used as a Flatpak. Not sure about preinstalling, but running Firefox ESR is probably not very cool. Also, some people might want to update their browser while not rebooting their system.
The fix
Bubblejail allows to sandbox system applications with a more flexible bubblejail sandbox, in theory allowing an RPM firefox to run, sandbox its processes and still be sandboxed itself.
It requires /usr/share/applications/ desktop entries for now, so it does not work for things like the Firefox tar archive.
Also, Firefox doesnt like it at all, I got tons of strange issues like crashes and things that felt like memory leaks.
Chromium on the other hand works fine afaik, and could already profit from bubblejail.
Security certificates / levels in Anaconda
Currently, the security presets in the Anaconda installer dont work either, not sure how this could be fixed.
The secureblue project has done a lot of testing, following a "if it may be insecure or we dont know how to fix it, we turn it off" approach.
This results in an often worse UX, but the benefits are there.
Big issues are especially
- removals of base packages, which cannot be layered again, due to how OCI container builds work
- firewall rules being all removed, making some things hard to get working again
A ton of other issues where ironed out already.
## kernel arguments
For example the kargs, [included in their just file](https://github.com/secureblue/secureblue/blob/live/files/system/usr/share/ublue-os/just/70-secureblue.just).
I discovered a bug back then on my crappy Lenovo Thinkpad firmware, so some are called "unstable" (they are not unstable, they simply break boot on some strange proprietary firmware). I run 3 coreboot laptops (EDK2, Heads, Dasharo) all with those "unstable" kargs without issues.
## disabling/enabling CUPS on demand
This is always a good measurement.
## hardened_malloc
This is a security hardened memory allocator, forked by GrapheneOS developers from the OpenBSD project. It works really fine on Desktop linux too. Chromium works, desktops and apps all work.
using hardened_malloc has some drawbacks, mainly:
- the implementation is not clean, normally you would need to recompile glibc with hardend_malloc afaik. Instead, secureblue just preloads it with LD_PRELOAD
- firefox uses it's own memory allocator "mozjemalloc" which results in a crash when using hardened_malloc with LD_PRELOAD. For that reason, Fedora Firefox allows using different mallocs and I tested it and it works. Torbrowser devs thought about it, not sure about the progress in Librewolf, may be done too.
- Electron apps dont use hardened_malloc because they do some magic
- flatpak apps need a whole in their sandbox to read that library. otherwise, a flatpak runtime extension would be needed, which doesnt yet exist
- the LD_PRELOAD method may just not break the system as many components dont respect it.
- when recompiling core components for hardened_malloc, you dont have a fallback, like you have in GrapheneOS (where you can disabled hardened_malloc per app)
## removal of insecure remote desktop apps
KRFP (VNC) is an example, it supposedly works but is unencrypted?
Instead, KRDP (RDP) can be used, but RDP requires nonfree codecs like h264 afaik.
Not sure about GNOME.
## [bubblejail](https://github.com/igo95862/bubblejail/issues)
This is a pre-release application, more or less experimental. It is [built on COPR](https://copr.fedorainfracloud.org/coprs/secureblue/bubblejail) using [this](https://github.com/secureblue/fedora-extras/tree/main/bubblejaill) or [this](https://github.com/rusty-snake/fedora-extras/tree/main/bubblejail) spec file.
### Background, Browser Sandboxes
Flatpak has some issues, like the generalized but restrictive seccomp filter on all apps.
That filter prevents apps from creating their own user namespaces, meaning browsers cannot normally work.
Chromium uses a fork server called "zygote" which can be tricked to use "flatpak spawn" instead, so Chromium browsers kinda work. The security of that process is unclear, it may not be well enough restricted (especially comparing the amounts of money flowing into bubblewrap vs. the Chromium process Sandbox) but in theory it can be better, as the browser itself is sandboxed too.
Firefox... has no fork server, so it cannot use this approach. The Flatpak is insecure and simply doesnt use any filesystem sandboxing with namespaces at all. Instead it just uses seccomp-bpf and that is it.
This means, Firefox should not be used as a Flatpak. Not sure about preinstalling, but running Firefox ESR is probably not very cool. Also, some people might want to update their browser while not rebooting their system.
### The fix
Bubblejail allows to sandbox system applications with a more flexible bubblejail sandbox, in theory allowing an RPM firefox to run, sandbox its processes and still be sandboxed itself.
It requires /usr/share/applications/ desktop entries for now, so it does not work for things like the Firefox tar archive.
Also, Firefox doesnt like it at all, I got tons of strange issues like crashes and things that felt like memory leaks.
Chromium on the other hand works fine afaik, and could already profit from bubblejail.
## Security certificates / levels in Anaconda
Currently, the security presets in the Anaconda installer dont work either, not sure how this could be fixed.