Nix multi-user installer fails on Fedora Rawhide due to SELinux denial

[outergod]

I have just come across this trying to install Nix on Fedora 28 Workstation with SELinux enabled (default) using the ./install-multi-user script from the nix-2.0.4-x86_64-linux bundle.

---- sudo execution ------------------------------------------------------------
I am executing:

    $ sudo systemctl link /nix/var/nix/profiles/default/lib/systemd/system/nix-daemon.service                                                                                

to set up the nix-daemon service

Failed to link unit: Access denied

I can confirm this is an SELinux denial due to this AVC message in /var/log/audit/audit.log:

type=AVC msg=audit(1535267537.912:2983): avc:  denied  { read } for  pid=1 comm="systemd" name="default" dev="nvme0n1p7" ino=2095622 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=lnk_file permissive=0 

This issue seems to be the same as the one discussed in #nixos-dev.

Based on the nature of the error, I would naturally assume all SELinux-enabled systems would be affected by this.

[dezgeg]

Yeah, probably the installer should bail out if SELinux is enforcing (at least for now).

[grahamc]

This bug is especially important now, the default installer as of 2.1 will detect systemd and default to the multi-user installer. See the attached PDF for a demonstration of the problem. (caution: big)
report-d-2.pdf

[grahamc]

Adding this logic:

        if /usr/sbin/sestatus && /usr/sbin/sestatus 2>&1 | grep -q enforcing; then
            echo "punting to no-daemon"
                curl "${installUrl}" | sh -s -- --no-daemon
        else 
                  curl "${installUrl}" | sh
        fi

worked in the test harness, but the following did not:

        if sestatus && sestatus 2>&1 | grep -q enforcing; then
            echo "punting to no-daemon"
                curl "${installUrl}" | sh -s -- --no-daemon
        else 
                  curl "${installUrl}" | sh
        fi

because the install script, when run over SSH, doesn't have /usr/sbin in the PATH.

I'm not sure the nicest way to do this, but we could try adding a few directories to the PATH (/sbin, /usr/sbin, others ...?) just for this check.

Another option is we do a naive check for sestatus and assume it is in the PATH and leave it up to the users to handle it otherwise.

Any ideas / recommendations?

[dezgeg]

The getenforce command should be better for scripting.

Perhaps:

getenforce=$(PATH=$PATH:/sbin:/usr/sbin command -v getenforce)
if [ -n "$getenforce" ] && [ "$($getenforce)" = Enforcing ]; then
    echo "No multi-user for you, sorry"
fi

[outergod]

Sorry for the stupid question, but why not just set proper SELinux file contexts for everything in /nix and restorecon those contexts on installation as well as after manipulating the store? I could just get a service in /nix/store to run using my system's systemd after executing

semanage fcontext -a -t bin_t '/nix/store/[^/]+/bin(/.*)?' 
semanage fcontext -a -t lib_t '/nix/store/[^/]+/lib(/.*)?' 
restorecon -R /nix/store

This is also akin to the default file contexts for /opt:

/opt/(.*/)?bin(/.*)?	system_u:object_r:bin_t:s0
/opt/(.*/)?lib(/.*)?	system_u:object_r:lib_t:s0
/opt/(.*/)?man(/.*)?	system_u:object_r:man_t:s0
(etc)

This could be easily integrated into the installation, and later more ideally with Nix in general and nix-store in particular.

Edit: After setting the profile symlinks in /nix/var/nix/profiles/ to usr_t, I was also able to run a service pointing to a profile directory because now systemd happily follows the symlinks, and it's easily arguable that user environments correspond to /usr.

[dezgeg]

Because I personally don't know anything about writing SELinux rules for Fedora (nor CentOS for that matter.

Don't you also need something to allow systemd to use socket activation for the Nix daemon? At least I ran into similar issue to ganto/copr-lxd#12.

[outergod]

Since I need to be able to run Nix based services, I will try my best to provide patches for the installer and possibly nix-store to integrate with SELinux properly.

[dezgeg]

Yes, that sounds good. I think we still need some quick solution for Nix 2.1.

[outergod]

Newly filed, related issue: systemd/systemd#9997

[outergod]

@dezgeg you might want to check out outergod@2d53311, which depends on NixOS/nixpkgs#46028 to be built. You could easily argue the policy belongs directly into nixpkgs because it provides value beyond the installation on non-NixOS systems. But as a first step, this should solve the issue of running Nix in multi-user mode in SELinux-enabled systems, but will not work once Nix is updated after installation - that could be fixed as a second step but requires some discussion as to how file contexts are preserved/restored when writing out derivations into the store:

1. SELinux file contexts can be baked directly into all derivations - which would make SELinux an integral part of Nix and might not be desired but requires no further changes to nix-store.
2. nix-store could be compiled with optional, direct SELinux support and write out file labels according to current, active policies. This is what systemd does when e.g. creating listening sockets.
3. nix-env and nix-store could should invoke restorecon after operating on profiles and the store, respectively - it's cheap and requires no deep, further modifications to any other tool.