by westurner | 2025-04-08 00:50:18+00:00
There's also the Fedora SELinux policy and the container-selinux policy set.

Rootless containers with podman lack labels like virtualenvs and NixOS.

Distrobox and toolbox set a number of options for rootless and regular containers;

--userns=keepid --security-opt=label=disable -v /tmp/path:/tmp/path:Z -v /tmp/path:/tmp/path:z --gpus all

"How Nix Works" https://nixos.org/guides/how-nix-works/ :

How Nix works: builds have a cache key that's a hash of all build parameters - /nix/store/<cachekey> - so that atomic upgrades and rollback work.

How NixOS works: config files are also snapshotted at a cache key for rollback and atomic upgrades that don't fail if interrupted mid-package-install.

> A big implication of the way that Nix/NixOS stores packages is that there is no /bin, /sbin, /lib, /usr, and so on. Instead all packages are kept in /nix/store. (The only exception is a symlink /bin/sh to Bash in the Nix store.) Not using ‘global’ directories such as /bin is what allows multiple versions of a package to coexist. Nix does have a /etc to keep system-wide configuration files, but most files in that directory are symlinks to generated files in /nix/store.

But which files should be assigned which extended filesystem attribute labels; signed packages only, local builds of [GPU drivers, out-of-tree modules,], not-yet-packaged things like ProtonGE;

I remembered hearing that Bazzite ships with Nix.

This [1] describes installing with the nix-determinate-installer [2] and then [3] installing home-manager :

nix run nixpkgs#home-manager -- switch --flake nix/#$USER

[1] https://universal-blue.discourse.group/t/issue-installing-ce...

[2] https://github.com/DeterminateSystems/nix-installer

[3] https://nixos.wiki/wiki/Home_Manager

Working with rpm-ostree; upgrading the layered firefox RPM without a reboot requires -A/--apply-live (which runs twice) and upgrading the firefox flatpak doesn't require a reboot, but SELinux policies don't apply to flatpaks which run unconfined FWIU.

"SEC: Flatpak Chrome, Chromium, and Firefox run without SELinux confinement?" https://discussion.fedoraproject.org/t/sec-flatpak-chrome-ch...

From https://news.ycombinator.com/item?id=43564972 :

> Flatpaks bypass selinux and apparmor policies and run unconfined (on DAC but not MAC systems) because the path to the executable in the flatpaks differs from the system policy for /s?bin/* and so wouldn't be relabeled with the necessary extended filesystem attributes even on `restorecon /` (which runs on reboot if /.autorelabel exists).*

Having written a venv_relabel.sh script to copy selinux labels from /etc onto $VIRTUAL_ENV/etc , IDK; consistently-built packages are signed and maintained. The relevant commands from that script: https://github.com/westurner/dotfiles/blob/develop/scripts/v... :

sudo semanage fcontext --modify -e "${_equalpth}" "${_path}"; sudo restorecon -Rv "${_path}";

Is something like this necessary for every /nix/store/<key> directory?

sudo semanage fcontext --modify -e "/etc" "${VIRTUAL_ENV}/etc"; sudo restorecon -Rv "${VIRTUAL_ENV}/etc";

Or is there a better way to support chroots with selinux with or without extending the existing SELinux functionality?