2.4.3.1 Installing the SELinux policy

To install the policy run this command as root:

semodule -i etc/guix-daemon.cil

Then relabel the file system with restorecon or by a different mechanism provided by your system.

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 command:

ps -Zax | grep guix-daemon

Monitor the SELinux log files as you run a command like guix build hello to convince yourself that SELinux permits all necessary operations.

2.4.3.2 Limitations

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.

1. guix_daemon_socket_t isn’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.
2. guix gc cannot 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 gc would be prevented from reading and following these links.
3. The daemon’s feature to listen for TCP connections might no longer work. This might require extra rules, because SELinux treats network sockets differently from files.
4. Currently all files with a name matching the regular expression /gnu/store/.+-(guix-.+|profile)/bin/guix-daemon are 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_t domain. 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_t domain. 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 effectively running guix-daemon executable is upgraded.