Merge branch 'live' into brewunused

docs/CONTRIBUTING.md

@@ -102,6 +102,47 @@ This usually involved editing the `Containerfile`. Most techniques for building
 
 Check out CoreOS's [layering examples](https://github.com/coreos/layering-examples) for more information on customizing.
 
+## Using Blue-build locally
+### Requirements
+
+- [Blue-build CLI](https://github.com/blue-build/cli)
+- Podman
+- git
+
+Secureblue already includes `bluebuild` but running locally requires customizing policy.json for your user to allow pulling a few unsigned images.
+
+#### Policy.json configuration
+
+On secureblue only pre-configured signed images are allowed to be pulled. Following repos need to be configured:
+
+- docker.io/mikefarah/yq `Unsigned`
+- ghcr.io/blue-build/cli `Unsigned`
+- ghcr.io/blue-build/modules `Unsigned`
+- quay.io/fedora-ostree-desktops `Unsigned`
+
+Copy `/etc/containers/policy.json` to `~/.config/containers/policy.json` and then add rules using podman CLI:
+
+- `podman image trust set --type accept docker.io/mikefarah/yq`
+- `podman image trust set --type accept ghcr.io/blue-build`
+- `podman image trust set --type accept quay.io/fedora-ostree-desktops`
+
+### Clone the repo
+
+    git clone https://github.com/secureblue/secureblue.git
+
+### Making changes
+
+Configuration is stored in `recipes` folder in form of YAML files. Other files to be added to the image are stored in `files`. `common` holds pluggable modules to add to your custom image. `general` and `securecore` hold configs for the desktop and server images, respectively. Documentation for modules can be found [here](https://blue-build.org/learn/getting-started/).
+
+### Building
+
+- Open terminal in root of your cloned repo.
+- Run `bluebuild build recipes/<your custom recipe>.yml`
+
+### Testing
+
+Run the image using `podman run` to get a root shell in your newly built image and verify the changes made prior.
+
 ## Styleguides
 ### Commit Messages
 

docs/USERNS.md

@@ -2,7 +2,7 @@
 
 [User namespaces](https://en.wikipedia.org/wiki/Linux_namespaces#User_ID_(user)) are a kernel feature introduced in kernel version 3.8. When an unprivileged user asks the kernel to create a namespace, the kernel needs to permit that user to do so. Whether this is permitted by the kernel is controlled via a sysctl flag.
 
-There is a [long history](https://madaidans-insecurities.github.io/linux.html#kernel) of vulnerabilities made possible by allowing this functionality for unprivileged users ever since its [introduction](https://gitlab.com/apparmor/apparmor/-/wikis/unprivileged_userns_restriction). Given this history, you might think we should just disable this functionality altogether. However if this functionality is disabled, then flatpak can't function without the suid bit set on the bubblewrap binary. In this scenario bubblewrap creates namespaces on behalf of the user instead of the kernel, by running as root. This means trusting bubblewrap (a significantly less battle-tested piece of software than the kernel) to run as root. However, some see this as still a preferable tradeoff (trusting one small program with root in exchange for reducing the kernel's attack surface).
+There is a [long history](https://madaidans-insecurities.github.io/linux.html#kernel) of vulnerabilities made possible by allowing this functionality for unprivileged users ever since its [introduction](https://gitlab.com/apparmor/apparmor/-/wikis/unprivileged_userns_restriction). Given this history, you might think we should just disable this functionality altogether. However if this functionality is disabled, then flatpak can't function without the suid bit set on the bubblewrap binary (which is set in no-userns images). In this scenario bubblewrap creates namespaces on behalf of the user instead of the kernel, by running as root. This means trusting bubblewrap (a significantly less battle-tested piece of software than the kernel) to run as root. However, some see this as still a preferable tradeoff (trusting one small program with root in exchange for reducing the kernel's attack surface).
 
 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 not included in the non-userns images.
 

files/system/etc/containers/registries.d/cosign-release.yaml

@@ -0,0 +1,3 @@
+docker:
+  gcr.io/projectsigstore:
+    use-sigstore-attachments: true

files/system/etc/pki/containers/cosign-release.pub

@@ -0,0 +1,4 @@
+-----BEGIN PUBLIC KEY-----
+MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEhyQCx0E9wQWSFI9ULGwy3BuRklnt
+IqozONbbdbqz11hlRJy9c7SG+hdcFl9jE9uE/dwtuwU2MqU9T/cN0YkWww==
+-----END PUBLIC KEY-----

files/system/usr/etc/containers/policy.json

@@ -6,6 +6,15 @@
   ],
   "transports": {
       "docker": {
+        "gcr.io/projectsigstore": [
+            {
+                "type": "sigstoreSigned",
+                "keyPath": "/etc/pki/containers/cosign-release.pub",
+                "signedIdentity": {
+                    "type": "matchRepository"
+                }
+            }
+        ],
         "ghcr.io/wayblueorg": [
           {
             "type": "sigstoreSigned",