Merge pull request #107 from grapheneloverdev/secureblue-docs-changes

Update Secureblue docs regarding namespaces

src/content/docs/os-security/linux.md

@@ -78,13 +78,11 @@ Similarly to how a lot of distributions maintain their own kernel, the same is t
 [Ubuntu](https://ubuntu.com/download) also has a [list](https://wiki.ubuntu.com/Security/Features) of mitigations they apply, including [using](https://wiki.ubuntu.com/Security/Features#kernel-lockdown:~:text=for%20regression%20tests.-,Built%20with%20%2Dfcf%2Dprotection,-Instructs%20the%20compiler) intel's [CFI](https://www.intel.com/content/www/us/en/developer/articles/technical/technical-look-control-flow-enforcement-technology.html), which is an important exploit mitigation, even if not as extensive as [hardened_malloc](https://github.com/GrapheneOS/hardened_malloc). However The Problems with backporting and outdated packages described prior still stand. 
 
 [Secureblue](https://github.com/secureblue/secureblue) has a [couple mitigations](https://github.com/secureblue/secureblue?tab=readme-ov-file#hardening) that are unique to it. The project comes with [hardened_malloc](https://github.com/GrapheneOS/hardened_malloc) preinstalled by default for both rpms and flatpaks. The project even goes as far as having it's [hardened-chromium](https://github.com/secureblue/hardened-chromium) subproject, which is inspired by [Vanadium](https://github.com/GrapheneOS/Vanadium) and uses [Fedora's Chromium](https://src.fedoraproject.org/rpms/chromium) as a base. The project only recommends the use of Gnome images, as it is the only DE that prevents apps from accessing screen content at the time of writing, KDE has plans to implement it, but hasn't done so yet.<sup>[4](https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/7)</sup> The project constantly tries to remove unnecessary attack surface if possible, this general mentality works very well for exploit mitigations and is what [GrapheneOS](https://grapheneos.org/) describes as the first step defending against unkown vulnerabilities.<sup>[5](https://grapheneos.org/features#exploit-protection)</sup>
-The Project also has images without [User namespaces](https://www.man7.org/linux/man-pages/man7/user_namespaces.7.html), which allow unpriveleged users to interact with parts of the Kernel which are reserved for root, this is cause for many attack vectors using privelege escalation. Disabling this feature breaks funcionality like [Toolbox](https://containertoolbx.org/) and means flatpak can't function without suid set to the bubblewrap binary, therefore bubblewrap creates namespaces instead of the user, in other words it runs as root. As the Project puts it:
+The Project also has globally disabled [User namespaces](https://www.man7.org/linux/man-pages/man7/user_namespaces.7.html) by default, which allow unpriveleged users to interact with parts of the Kernel which are reserved for root, this is cause for many attack vectors using privelege escalation. Disabling this feature breaks functionality like [Toolbox](https://containertoolbx.org/) and means flatpak can't function without suid set to the bubblewrap binary, therefore bubblewrap creates namespaces instead of the user, in other words it runs as root. As the Project puts it:
 
-> Ultimately we leave both options available because it's a tradeoff and neither is demonstrably preferable from a security standpoint. It should also be noted that podman, toolbox, and distrobox require unprivileged user namespaces to function and are therefore [removed in the non-userns images](https://github.com/secureblue/secureblue/blob/live/recipes/common/disableuserns-packages.yml).
+> you might think we should just disable this functionality altogether. However if this functionality is disabled globally, then flatpak can't function. To mitigate this, we first revoke user_namespace privileges from the unconfined domain in our selinux policy. Then, we confine flatpak and grant it user_namespace privileges. We do the same for hardened-chromium. This allows them to create user namespaces while keeping them globally disabled by default. We don't do this for bwrap or podman directly because the syscall filters for both are weak by default. If you need container domain userns (e.g. for distrobox), you can enable it with `ujust toggle-container-domain-userns-creation`. If you need to use any other software that requires user namespace creation privileges (e.g. bubblejail), you can enable it with `ujust toggle-unconfined-domain-userns-creation`. But keep in mind that this is a security degradation.
 > 
 > Canonical considers user namespaces to be a substantial risk, too, and has restricted them via a global AppArmor policy [since 23.10 by opt-in](https://discourse.ubuntu.com/t/spec-unprivileged-user-namespace-restrictions-via-apparmor-in-ubuntu-23-10/37626) and [since 24.04 by default](https://ubuntu.com/blog/whats-new-in-security-for-ubuntu-24-04-lts).
 > 
-> Future endeavours should aim at bringing comparable, granular restrictions via a global SELinux policy, ideally upstream in Fedora.
-> 
-> [Source](https://github.com/secureblue/secureblue/blob/live/USERNS.md)
+> [Source](https://github.com/secureblue/secureblue/blob/live/docs/USERNS.md)