WEwesturner·Apr 8, 2025
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 kep
Read the rest
t 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?