add missing SELinux directives

[kbknapp]

Description

Fixes #1030

On a Fedora 40 system where /nix is a ZFS dataset there were several missing SELinux directives.

Checklist

• Formatted with cargo fmt
• Built with nix build
• Ran flake checks with nix flake check
• Added or updated relevant tests (leave unchecked if not applicable)
• Added or updated relevant documentation (leave unchecked if not applicable)
• Linked to related issues (leave unchecked if not applicable)

[grahamc]

I'd like to recompile the policy file and make sure I get the same output. done. I have a ping out to a buddy, hoping to get a bit of secondary feedback on this. If I don't hear back soon let's go ahead with it.

[grahamc]

I'm surely no expert with SELinux, so this might be an obvious question but ... did this policy do anything before? Why did we have it? Yes. The relevant pieces are in the associated .fc file.

[NeilHanlon]

putting a public note here so I remember -- giving init_t full access to read default_t:lnk_file is probably not the "most correct" solution, as it is overly broad, despite being the solution recommended by audit2allow. I will try and spend some time on this next week (as I also use detsys nix on Fedora :) )

[kbknapp]

Yeah there is almost certainly a more targeted policy that could be used, in fact I see a few places where the default_t domain is used and I'm guessing something like a nix_t domain would be more appropriate?

$  ls -lZ /nix/var/nix/profiles/default 
lrwxrwxrwx - root system_u:object_r:bin_t:s0     31 Dec  1969 bin -> /nix/store/00dc6iygj63mjcmixki1vwg7m1jbdi9p-nix-2.21.2/bin
dr-xr-xr-x - root system_u:object_r:etc_t:s0     31 Dec  1969 etc
lrwxrwxrwx - root system_u:object_r:lib_t:s0     31 Dec  1969 lib -> /nix/store/00dc6iygj63mjcmixki1vwg7m1jbdi9p-nix-2.21.2/lib
lrwxrwxrwx - root system_u:object_r:default_t:s0 31 Dec  1969 libexec -> /nix/store/00dc6iygj63mjcmixki1vwg7m1jbdi9p-nix-2.21.2/libexec
lrwxrwxrwx - root system_u:object_r:default_t:s0 31 Dec  1969 manifest.nix -> /nix/store/3681kssclgak8rcvk9a0jhbpfcmm3sjq-env-manifest.nix
lrwxrwxrwx - root system_u:object_r:usr_t:s0     31 Dec  1969 share -> /nix/store/00dc6iygj63mjcmixki1vwg7m1jbdi9p-nix-2.21.2/share

---

Back to the original issue, I'm not sure exactly why that symlink was labeled default_t in the first place, because now that everything installed it's labeled systemd_unit_file_t at both ends:

$ ls -lZ /etc/systemd/system/nix-daemon.service                                                      
lrwxrwxrwx - root unconfined_u:object_r:systemd_unit_file_t:s0  2 Jul 08:37 /etc/systemd/system/nix-daemon.service -> /nix/var/nix/profiles/default/lib/systemd/system/nix-daemon.service
$ ls -lZ /nix/var/nix/profiles/default/lib/systemd/system/nix-daemon.service                                                
.r--r--r-- 430 root system_u:object_r:systemd_unit_file_t:s0 31 Dec  1969 /nix/var/nix/profiles/default/lib/systemd/system/nix-daemon.service

[emilazy]

Back to the original issue, I'm not sure exactly why that symlink was labeled default_t in the first place, because now that everything installed it's labeled systemd_unit_file_t at both ends:

The Determinate Systems installer turns automatic store optimization on. SELinux labels files, not paths. So when two identical files get hard‐linked together, labels can get messed up. nix-store --optimise is basically a request to corrupt your store on an SELinux system, and auto-optimise-store is even worse. Sorry, I kept meaning to properly report this and never got around to it, but I also ran into this problem all the time and narrowed it down to store optimization, and I just came across this PR, so I figured I should at least post this.

[NeilHanlon]

That's very helpful to know, thanks @emilazy !

[kbknapp]

It sounds like the optimize process either just needs to learn to restorecon, or whatever is scheduling the optimize could add that after? I'm assuming this is far easier said than done, of course 😄

[emilazy]

I believe that restorecon isn’t enough; the problem is that you can have “the same file” (because of hard‐links) with two possible labels (e.g. because one version is in the bin directory of a derivation and another isn’t). I didn’t narrow down a minimal reproduction case but fiddling around led me to the conclusion that the current store optimization process just isn’t fit for purpose in the presence of SELinux.

[kbknapp]

Ah ok, that makes sense thanks! Yeah I don't know of a way out that conundrum since from what I understand; SELinux just labels based off "last matched" when it comes to multiple links point to the same inode. There is an option to hard error (i.e. setfiles -E) in such a case, but that doesn't help anything here where by design nix expects such conflicts to occur on optimize.

[emilazy]

I think the installer should just turn off auto-optimise-store on SELinux systems, and in an ideal world trying to do a manual optimization would flag up a big red warning. You could do fancier stuff like checking that the files would get the same label before linking, but it really doesn’t feel worth it to me. (What if you change the policy afterwards?)