From 32d66fd2cd29525735821f1cf9a244bbf8242a0c Mon Sep 17 00:00:00 2001 From: RoyalOughtness <129108030+RoyalOughtness@users.noreply.github.com> Date: Fri, 28 Feb 2025 13:49:54 -0800 Subject: [PATCH 01/10] feat: add information FAQ items --- content/FAQ.md | 21 +++++++++++++++++++++ content/INDEX.md | 2 +- 2 files changed, 22 insertions(+), 1 deletion(-) diff --git a/content/FAQ.md b/content/FAQ.md index 94002493..9ae07215 100644 --- a/content/FAQ.md +++ b/content/FAQ.md @@ -9,6 +9,8 @@ permalink: /faq ## [Table of contents](#table-of-contents) {: #table-of-contents} +- [Why secureblue?](#why) +- [Is this an install script?](#script) - [Why is Flatpak included? Should I use Flatpak?](#flatpak) - [Should I use Electron apps? Why don't they work well with hardened_malloc?](#electron) - [My fans are really loud, is this normal?](#fans) @@ -40,6 +42,25 @@ permalink: /faq - [How do I add a repo?](#adding-repos) - [How do I install proprietary codecs?](#install-codecs) - [How do I change my DE?](#change-de) + + +### [Why secureblue?](#secureblue) +{: #secureblue} + +secureblue is a collaborative effort to ship a maximally secure Linux operating system. It leverages [bootable container](https://github.com/containers/bootc) technology to build on top of Fedora Atomic, without the need to become a distro in the traditional sense. secureblue has benefitted massively by not being a distro, and instead shipping as bootable OCI container images. This has meant a ton of overhead is taken care of for us by Fedora. We don’t need general repos or packaging, except for a handful of specific packages (Trivalent, hardened_malloc, etc). The Fedora Atomic ecosystem is also rich in tooling and automation (see: [BlueBuild](https://blue-build.org/)), plus the backdrop of robust container technology that already exists. All of this has largely enabled us to focus our energy on improving secureblue's hardening and UX, developing [Trivalent](https://github.com/secureblue/Trivalent), and building out userspace SELinux policies. + +### [Why not upstream your changes?](#upstream) +{: #upstream} + +When possible, we do upstream our changes. For example, collaborating with KDE to make [portal improvements](https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/347). However, it's important to note that many of the changes we make are not possible to upstream, generally due to upstream not desiring them. This is for good reason. + +Many of the changes secureblue makes will necessarily break someone’s use case by default. Otherwise, secureblue could just submit all of our changes upstream to Fedora. Take appimage support as an example. Appimages depend on the suid-root, deprecated, unmaintained fuse2 interface. They also encourage users to follow the security antipattern of downloading and executing binaries from the browser. Yet, since Appimages are widely used, Fedora can’t remove support for them. secureblue is willing to do so for security reasons, by default, with mechanisms available for users to re-enable support if needed for their use cases. + +### [Is this an install script?](#script) +{: #script} + +No. When you run our installer, you are *fully replacing* the system. secureblue is not an install script, nor a distro in the traditional sense. It is a set of [bootable container](https://github.com/containers/bootc) images shipped via GitHub's container registry. These images are rebuilt daily and pushed to GitHub's container registry. These images are then then pulled in by `rpm-ostree`, which stages updates as a pending deployment for the next boot. To view information about your current local deployments and remotes, run `rpm-ostree status`. + ### [Why is Flatpak included? Should I use Flatpak?](#flatpak) {: #flatpak} diff --git a/content/INDEX.md b/content/INDEX.md index 922e8d72..47426994 100644 --- a/content/INDEX.md +++ b/content/INDEX.md @@ -6,7 +6,7 @@ permalink: / ## [About](#about) -secureblue is a security-focused desktop and server linux operating system, developed as an open-source project. It is shipped as a set of [OCI](https://en.wikipedia.org/wiki/Open_Container_Initiative) bootable container images, which are generated with [BlueBuild](https://blue-build.org/), using [Fedora Atomic Desktop](https://fedoraproject.org/atomic-desktops/)'s [base images](https://pagure.io/workstation-ostree-config) as a starting point. Fedora is one of the few Linux distributions that ships with SELinux and associated tooling built-in and enabled by default. This makes it advantageous as a starting point for building a secure desktop system. However, the security posture of desktop linux is broadly and significantly lacking. The goal of secureblue is to build a maximally secure linux operating system by proactively increasing defenses against the exploitation of both known and unknown vulnerabilities while avoiding sacrificing usability for most use cases where possible. For more details, see the [features list](/features). +secureblue is a security-focused desktop and server linux operating system, developed as an open-source project. It is shipped as a set of [OCI](https://en.wikipedia.org/wiki/Open_Container_Initiative) bootable container images, which are generated with [BlueBuild](https://blue-build.org/), using [Fedora Atomic Desktop](https://fedoraproject.org/atomic-desktops/)'s [base images](https://pagure.io/workstation-ostree-config) as a starting point. Fedora is one of the few Linux distributions that ships with SELinux and associated tooling built-in and enabled by default. This makes it advantageous as a starting point for building a secure desktop system. However, the security architecture of desktop linux is broadly and significantly lacking. The goal of secureblue is to build a maximally secure linux operating system by proactively increasing defenses against the exploitation of both known and unknown vulnerabilities while avoiding sacrificing usability for most use cases where possible. For more details, see the [features list](/features). ## [Who is secureblue for?](#who-is-secureblue-for) From 152537ac2965a4c7d3f95c46dac60877ced01107 Mon Sep 17 00:00:00 2001 From: RoyalOughtness <129108030+RoyalOughtness@users.noreply.github.com> Date: Fri, 28 Feb 2025 13:50:49 -0800 Subject: [PATCH 02/10] TOC --- content/FAQ.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/FAQ.md b/content/FAQ.md index 9ae07215..ce7c8e6d 100644 --- a/content/FAQ.md +++ b/content/FAQ.md @@ -10,6 +10,7 @@ permalink: /faq ## [Table of contents](#table-of-contents) {: #table-of-contents} - [Why secureblue?](#why) +- [Why not upstream your changes?](#upstream) - [Is this an install script?](#script) - [Why is Flatpak included? Should I use Flatpak?](#flatpak) - [Should I use Electron apps? Why don't they work well with hardened_malloc?](#electron) From a1fe993f944fd6940268bb574959f2f83833adc6 Mon Sep 17 00:00:00 2001 From: RoyalOughtness <129108030+RoyalOughtness@users.noreply.github.com> Date: Fri, 28 Feb 2025 13:51:36 -0800 Subject: [PATCH 03/10] fix TOC --- content/FAQ.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/FAQ.md b/content/FAQ.md index ce7c8e6d..e73b7a43 100644 --- a/content/FAQ.md +++ b/content/FAQ.md @@ -9,7 +9,7 @@ permalink: /faq ## [Table of contents](#table-of-contents) {: #table-of-contents} -- [Why secureblue?](#why) +- [Why secureblue?](#secureblue) - [Why not upstream your changes?](#upstream) - [Is this an install script?](#script) - [Why is Flatpak included? Should I use Flatpak?](#flatpak) From c7451b7fc7cf3fc18c9f9e3ef544a84878abb912 Mon Sep 17 00:00:00 2001 From: RoyalOughtness <129108030+RoyalOughtness@users.noreply.github.com> Date: Fri, 28 Feb 2025 13:52:13 -0800 Subject: [PATCH 04/10] fix --- content/FAQ.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/FAQ.md b/content/FAQ.md index e73b7a43..d39559d9 100644 --- a/content/FAQ.md +++ b/content/FAQ.md @@ -48,7 +48,7 @@ permalink: /faq ### [Why secureblue?](#secureblue) {: #secureblue} -secureblue is a collaborative effort to ship a maximally secure Linux operating system. It leverages [bootable container](https://github.com/containers/bootc) technology to build on top of Fedora Atomic, without the need to become a distro in the traditional sense. secureblue has benefitted massively by not being a distro, and instead shipping as bootable OCI container images. This has meant a ton of overhead is taken care of for us by Fedora. We don’t need general repos or packaging, except for a handful of specific packages (Trivalent, hardened_malloc, etc). The Fedora Atomic ecosystem is also rich in tooling and automation (see: [BlueBuild](https://blue-build.org/)), plus the backdrop of robust container technology that already exists. All of this has largely enabled us to focus our energy on improving secureblue's hardening and UX, developing [Trivalent](https://github.com/secureblue/Trivalent), and building out userspace SELinux policies. +secureblue is a collaborative effort to ship a maximally secure Linux operating system. It leverages [bootable container](https://github.com/containers/bootc) technology to build on top of Fedora Atomic, avoiding the need to become a distro in the traditional sense. secureblue has benefitted massively by not being a distro, and instead shipping as bootable OCI container images. This has meant a ton of overhead is taken care of for us by Fedora. We don’t need general repos or packaging, except for a handful of specific packages (Trivalent, hardened_malloc, etc). The Fedora Atomic ecosystem is also rich in tooling and automation (see: [BlueBuild](https://blue-build.org/)), plus the backdrop of robust container technology that already exists. All of this has largely enabled us to focus our energy on improving secureblue's hardening and UX, developing [Trivalent](https://github.com/secureblue/Trivalent), and building out userspace SELinux policies. ### [Why not upstream your changes?](#upstream) {: #upstream} From c59ed2d6a47c8bb163d8fd3be73d1de33ab7224e Mon Sep 17 00:00:00 2001 From: RoyalOughtness <129108030+RoyalOughtness@users.noreply.github.com> Date: Fri, 28 Feb 2025 13:52:42 -0800 Subject: [PATCH 05/10] fix --- content/FAQ.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/content/FAQ.md b/content/FAQ.md index d39559d9..391cc315 100644 --- a/content/FAQ.md +++ b/content/FAQ.md @@ -53,9 +53,7 @@ secureblue is a collaborative effort to ship a maximally secure Linux operating ### [Why not upstream your changes?](#upstream) {: #upstream} -When possible, we do upstream our changes. For example, collaborating with KDE to make [portal improvements](https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/347). However, it's important to note that many of the changes we make are not possible to upstream, generally due to upstream not desiring them. This is for good reason. - -Many of the changes secureblue makes will necessarily break someone’s use case by default. Otherwise, secureblue could just submit all of our changes upstream to Fedora. Take appimage support as an example. Appimages depend on the suid-root, deprecated, unmaintained fuse2 interface. They also encourage users to follow the security antipattern of downloading and executing binaries from the browser. Yet, since Appimages are widely used, Fedora can’t remove support for them. secureblue is willing to do so for security reasons, by default, with mechanisms available for users to re-enable support if needed for their use cases. +When possible, we do upstream our changes. For example, collaborating with KDE to make [portal improvements](https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/347). However, it's important to note that many of the changes we make are not possible to upstream, generally due to upstream not desiring them. This is for good reason. Many of the changes secureblue makes will necessarily break someone’s use case by default. Otherwise, secureblue could just submit all of our changes upstream to Fedora. Take appimage support as an example. Appimages depend on the suid-root, deprecated, unmaintained fuse2 interface. They also encourage users to follow the security antipattern of downloading and executing binaries from the browser. Yet, since Appimages are widely used, Fedora can’t remove support for them. secureblue is willing to do so for security reasons, by default, with mechanisms available for users to re-enable support if needed for their use cases. ### [Is this an install script?](#script) {: #script} From 287e90d2149c96a552a9b8048a0c6a560f7db9b3 Mon Sep 17 00:00:00 2001 From: RoyalOughtness <129108030+RoyalOughtness@users.noreply.github.com> Date: Fri, 28 Feb 2025 13:53:12 -0800 Subject: [PATCH 06/10] fix --- content/FAQ.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/FAQ.md b/content/FAQ.md index 391cc315..50dbb1be 100644 --- a/content/FAQ.md +++ b/content/FAQ.md @@ -53,7 +53,7 @@ secureblue is a collaborative effort to ship a maximally secure Linux operating ### [Why not upstream your changes?](#upstream) {: #upstream} -When possible, we do upstream our changes. For example, collaborating with KDE to make [portal improvements](https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/347). However, it's important to note that many of the changes we make are not possible to upstream, generally due to upstream not desiring them. This is for good reason. Many of the changes secureblue makes will necessarily break someone’s use case by default. Otherwise, secureblue could just submit all of our changes upstream to Fedora. Take appimage support as an example. Appimages depend on the suid-root, deprecated, unmaintained fuse2 interface. They also encourage users to follow the security antipattern of downloading and executing binaries from the browser. Yet, since Appimages are widely used, Fedora can’t remove support for them. secureblue is willing to do so for security reasons, by default, with mechanisms available for users to re-enable support if needed for their use cases. +When possible, we do upstream our changes. For example, collaborating with KDE to make [portal improvements](https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/347). However, it's important to note that many of the changes we make are not possible to upstream, generally due to upstream not desiring them. This is for good reason. Many of the changes secureblue makes will necessarily break someone’s use case by default. Otherwise, secureblue could just submit all of our changes upstream to Fedora. Take appimage support as an example. Appimages depend on the suid-root, deprecated, unmaintained fuse2 interface. They also encourage users to follow the security antipattern of downloading and executing binaries from the browser. Yet, since Appimages are widely used, Fedora can’t remove support for them. secureblue is willing to do so by default to improve security, with mechanisms available for users to re-enable support if needed for their use cases. ### [Is this an install script?](#script) {: #script} From 5824acde447664cbceffdc069db80ebea7a1c7f0 Mon Sep 17 00:00:00 2001 From: RoyalOughtness <129108030+RoyalOughtness@users.noreply.github.com> Date: Fri, 28 Feb 2025 13:54:55 -0800 Subject: [PATCH 07/10] fix --- content/FAQ.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/FAQ.md b/content/FAQ.md index 50dbb1be..90826b79 100644 --- a/content/FAQ.md +++ b/content/FAQ.md @@ -58,7 +58,7 @@ When possible, we do upstream our changes. For example, collaborating with KDE t ### [Is this an install script?](#script) {: #script} -No. When you run our installer, you are *fully replacing* the system. secureblue is not an install script, nor a distro in the traditional sense. It is a set of [bootable container](https://github.com/containers/bootc) images shipped via GitHub's container registry. These images are rebuilt daily and pushed to GitHub's container registry. These images are then then pulled in by `rpm-ostree`, which stages updates as a pending deployment for the next boot. To view information about your current local deployments and remotes, run `rpm-ostree status`. +No. When you run our installer, you are *fully replacing* the system. secureblue is not an install script, nor an addon to a Fedora installation, nor a distro in the traditional sense. It is a set of [bootable container](https://github.com/containers/bootc) images shipped via GitHub's container registry. These images are rebuilt daily and pushed to GitHub's container registry. These images are then then pulled in by `rpm-ostree`, which stages updates as a pending deployment for the next boot. To view information about your current local deployments and remotes, run `rpm-ostree status`. ### [Why is Flatpak included? Should I use Flatpak?](#flatpak) {: #flatpak} From afc5416a156c3a1e99bd3134f997a710380335b3 Mon Sep 17 00:00:00 2001 From: RoyalOughtness <129108030+RoyalOughtness@users.noreply.github.com> Date: Fri, 28 Feb 2025 14:14:26 -0800 Subject: [PATCH 08/10] tweak wording --- content/INSTALL.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/INSTALL.md b/content/INSTALL.md index 7102b755..ecb53164 100644 --- a/content/INSTALL.md +++ b/content/INSTALL.md @@ -52,7 +52,7 @@ Before rebasing and during the installation, the following checks are recommende ## [Terms of use](#terms) {: #terms} -secureblue includes a combination of software packages, each under its own licensing terms. The license of secureblue is the Apache License 2.0. The license of secureblue does not supersede the licenses of code and content contained in secureblue. By downloading secureblue you agree to the license terms of its use. +secureblue includes a combination of software packages, each under its own licensing terms. The license of secureblue is the Apache License 2.0. The license of secureblue does not supersede the licenses of upstream code and content contained in secureblue images. By downloading secureblue you agree to the license terms of its use. ``` Copyright 2024-2025 The secureblue authors From ffa843b128e6a7fc5136726d12ae6a104ab0b479 Mon Sep 17 00:00:00 2001 From: RoyalOughtness <129108030+RoyalOughtness@users.noreply.github.com> Date: Thu, 13 Mar 2025 14:45:46 -0700 Subject: [PATCH 09/10] Update FAQ.md --- content/FAQ.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/FAQ.md b/content/FAQ.md index 90826b79..f87ade32 100644 --- a/content/FAQ.md +++ b/content/FAQ.md @@ -48,12 +48,12 @@ permalink: /faq ### [Why secureblue?](#secureblue) {: #secureblue} -secureblue is a collaborative effort to ship a maximally secure Linux operating system. It leverages [bootable container](https://github.com/containers/bootc) technology to build on top of Fedora Atomic, avoiding the need to become a distro in the traditional sense. secureblue has benefitted massively by not being a distro, and instead shipping as bootable OCI container images. This has meant a ton of overhead is taken care of for us by Fedora. We don’t need general repos or packaging, except for a handful of specific packages (Trivalent, hardened_malloc, etc). The Fedora Atomic ecosystem is also rich in tooling and automation (see: [BlueBuild](https://blue-build.org/)), plus the backdrop of robust container technology that already exists. All of this has largely enabled us to focus our energy on improving secureblue's hardening and UX, developing [Trivalent](https://github.com/secureblue/Trivalent), and building out userspace SELinux policies. +secureblue is a collaborative effort to ship a maximally secure Linux operating system. It leverages [bootable container](https://github.com/containers/bootc) technology to build on top of Fedora Atomic, avoiding the need to become a distro in the traditional sense. secureblue has benefitted massively by not being a distro, and instead shipping as bootable OCI container images. This has meant a ton of overhead is taken care of for us by Fedora. We don’t need general repos or packaging, except for a handful of specific packages ([Trivalent](https://github.com/secureblue/Trivalent), [hardened_malloc](https://github.com/GrapheneOS/hardened_malloc), etc). The Fedora Atomic ecosystem is also rich in tooling and automation (see: [BlueBuild](https://blue-build.org/)), plus the backdrop of robust container technology that already exists. All of this has largely enabled us to focus our energy on improving secureblue's hardening and UX, developing [Trivalent](https://github.com/secureblue/Trivalent), and building out userspace SELinux policies. ### [Why not upstream your changes?](#upstream) {: #upstream} -When possible, we do upstream our changes. For example, collaborating with KDE to make [portal improvements](https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/347). However, it's important to note that many of the changes we make are not possible to upstream, generally due to upstream not desiring them. This is for good reason. Many of the changes secureblue makes will necessarily break someone’s use case by default. Otherwise, secureblue could just submit all of our changes upstream to Fedora. Take appimage support as an example. Appimages depend on the suid-root, deprecated, unmaintained fuse2 interface. They also encourage users to follow the security antipattern of downloading and executing binaries from the browser. Yet, since Appimages are widely used, Fedora can’t remove support for them. secureblue is willing to do so by default to improve security, with mechanisms available for users to re-enable support if needed for their use cases. +When possible, we do upstream our changes. For example, collaborating with KDE to make [portal improvements](https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/347). However, it's important to note that many of the changes we make are not possible to upstream, generally due to upstream not desiring them. This is for good reason. Many of the changes secureblue makes will necessarily break someone’s use case by default. Otherwise, secureblue could just submit all of our changes upstream to Fedora. Take AppImage support as an example. AppImages depend on the suid-root, deprecated, unmaintained fuse2 interface. They also encourage users to follow the security antipattern of downloading and executing binaries from the browser. Yet, since AppImages are widely used, Fedora can’t remove support for them. secureblue is willing to do so by default to improve security, with mechanisms available for users to re-enable support if needed for their use cases. ### [Is this an install script?](#script) {: #script} From 76c8bb36fea8bf8dc68902e8621bdca2c53aa5e9 Mon Sep 17 00:00:00 2001 From: RoyalOughtness <129108030+RoyalOughtness@users.noreply.github.com> Date: Thu, 13 Mar 2025 14:56:23 -0700 Subject: [PATCH 10/10] Update FAQ.md --- content/FAQ.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/FAQ.md b/content/FAQ.md index da154939..647ce56b 100644 --- a/content/FAQ.md +++ b/content/FAQ.md @@ -55,7 +55,7 @@ secureblue is a collaborative effort to ship a maximally secure Linux operating ### [Why not upstream your changes?](#upstream) {: #upstream} -When possible, we do upstream our changes. For example, collaborating with KDE to make [portal improvements](https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/347). However, it's important to note that many of the changes we make are not possible to upstream, generally due to upstream not desiring them. This is for good reason. Many of the changes secureblue makes will necessarily break someone’s use case by default. Otherwise, secureblue could just submit all of our changes upstream to Fedora. Take AppImage support as an example. AppImages depend on the suid-root, deprecated, unmaintained fuse2 interface. They also encourage users to follow the security antipattern of downloading and executing binaries from the browser. Yet, since AppImages are widely used, Fedora can’t remove support for them. secureblue is willing to do so by default to improve security, with mechanisms available for users to re-enable support if needed for their use cases. +When possible, we do upstream our changes. For example, collaborating with KDE to make [portal improvements](https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/347). However, it's important to note that many of the changes we make are not possible to upstream, generally due to upstream not desiring them. This is for good reason. Many of the changes secureblue makes will necessarily break someone’s use case by default. Otherwise, secureblue could just submit all of our changes upstream to Fedora. Take AppImage support as an example. AppImages depend on the suid-root, deprecated, unmaintained fuse2 interface. They also encourage users to follow the security antipattern of downloading and executing binaries from the browser. Yet, since AppImages are widely used, Fedora can’t remove support for them. secureblue is willing make these kinds of changes by default to improve security, with mechanisms available for users to re-enable support if needed for their use cases. ### [Is this an install script?](#script) {: #script} @@ -298,4 +298,4 @@ DRM-protected content is available in trivalent, however it is disabled by defau ### [How do I enable kernel modules?](#enable-kernel-modules) {: #enable-kernel-modules} -Some functionality requires you to enable extra kernel modules that are disabled by default in secureblue. Modules can be enabled by running `ujust override-enable-module`. For instance, mounting SMB shares requires the `cifs` and `netfs` kernel modules. To load them, simply run `ujust override-enable-module cifs` and `ujust override-enable-module netfs` then reboot. \ No newline at end of file +Some functionality requires you to enable extra kernel modules that are disabled by default in secureblue. Modules can be enabled by running `ujust override-enable-module`. For instance, mounting SMB shares requires the `cifs` and `netfs` kernel modules. To load them, simply run `ujust override-enable-module cifs` and `ujust override-enable-module netfs` then reboot.