Guix includes an SELinux policy file at etc/guix-daemon.cil that can be installed on a system where SELinux is enabled, in order to label Guix files and to specify the expected behavior of the daemon. Since Guix System does not provide an SELinux base policy, the daemon policy cannot be used on Guix System.
guix-install.shbinary installation script offers to perform the steps below for you (see Binary Installation).
To install the policy run this command as root:
semodule -i /var/guix/profiles/per-user/root/current-guix/share/selinux/guix-daemon.cil
Then, as root, relabel the file system, possibly after making it writable:
mount -o remount,rw /gnu/store restorecon -R /gnu /var/guix
At this point you can start or restart
guix-daemon; on a
distribution that uses systemd as its service manager, you can do that
systemctl restart guix-daemon
Once the policy is installed, the file system has been relabeled, and
the daemon has been restarted, it should be running in the
guix_daemon_t context. You can confirm this with the following
ps -Zax | grep guix-daemon
Monitor the SELinux log files as you run a command like
hello to convince yourself that SELinux permits all necessary
This policy is not perfect. Here is a list of limitations or quirks that should be considered when deploying the provided SELinux policy for the Guix daemon.
guix_daemon_socket_tisn’t actually used. None of the socket operations involve contexts that have anything to do with
guix_daemon_socket_t. It doesn’t hurt to have this unused label, but it would be preferable to define socket rules for only this label.
guix gccannot access arbitrary links to profiles. By design, the file label of the destination of a symlink is independent of the file label of the link itself. Although all profiles under $localstatedir are labelled, the links to these profiles inherit the label of the directory they are in. For links in the user’s home directory this will be
user_home_t. But for links from the root user’s home directory, or /tmp, or the HTTP server’s working directory, etc, this won’t work.
guix gcwould be prevented from reading and following these links.
/gnu/store/.+-(guix-.+|profile)/bin/guix-daemonare assigned the label
guix_daemon_exec_t; this means that any file with that name in any profile would be permitted to run in the
guix_daemon_tdomain. This is not ideal. An attacker could build a package that provides this executable and convince a user to install and run it, which lifts it into the
guix_daemon_tdomain. At that point SELinux could not prevent it from accessing files that are allowed for processes in that domain.
You will need to relabel the store directory after all upgrades to
guix-daemon, such as after running
guix pull. Assuming the
store is in /gnu, you can do this with
restorecon -vR /gnu,
or by other means provided by your operating system.
We could generate a much more restrictive policy at installation time,
so that only the exact file name of the currently installed
guix-daemon executable would be labelled with
guix_daemon_exec_t, instead of using a broad regular expression.
The downside is that root would have to install or upgrade the policy at
installation time whenever the Guix package that provides the
guix-daemon executable is upgraded.