5 ms·

SELinux on NixOS

westurner 1y ago
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/ 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-certain-packages-using-nix/2473/4 https://universal-blue.discourse.group/t/issue-installing-ce... [2] https://github.com/DeterminateSystems/nix-installer https://github.com/DeterminateSystems/nix-installer [3] https://nixos.wiki/wiki/Home_Manager 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-chromium-and-firefox-run-without-selinux-confinement/141929 https://discussion.fedoraproject.org/t/sec-flatpak-chrome-ch... From https://news.ycombinator.com/item?id=43564972 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/venv_relabel.sh#L84-L85 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?
sunshine-o 1y ago
Some important work !

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/ 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-certain-packages-using-nix/2473/4 https://universal-blue.discourse.group/t/issue-installing-ce... [2] https://github.com/DeterminateSystems/nix-installer https://github.com/DeterminateSystems/nix-installer [3] https://nixos.wiki/wiki/Home_Manager 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-chromium-and-firefox-run-without-selinux-confinement/141929 https://discussion.fedoraproject.org/t/sec-flatpak-chrome-ch... From https://news.ycombinator.com/item?id=43564972 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/venv_relabel.sh#L84-L85 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?

sunshine-o 1y ago

Some important work !