denying read for systemd-sysctl on file in /run/sysctl.d

[dustymabe]

I'm creating a file in /run/sysctl.d to be picked up by systemd-sysctl and it's failing with an selinux denial. On Fedora 32:

$ sudo mkdir -p /run/sysctl.d
$ echo 'kernel.printk=4' | sudo tee /run/sysctl.d/20-printk.conf
kernel.printk=4
$ ls -lZ /run/sysctl.d/20-printk.conf
-rw-r--r--. 1 root root unconfined_u:object_r:var_run_t:s0 16 Apr 15 21:15 /run/sysctl.d/20-printk.conf
$ 
$ matchpathcon /run/sysctl.d/20-printk.conf 
/run/sysctl.d/20-printk.conf    system_u:object_r:var_run_t:s0
$ 
$ sudo systemctl restart systemd-sysctl
Job for systemd-sysctl.service failed because the control process exited with error code.
See "systemctl status systemd-sysctl.service" and "journalctl -xe" for details.
$ 
$ sudo journalctl --since '60 seconds ago' | grep AVC
Apr 15 21:16:14 vanilla-f32-beta audit[2454]: AVC avc:  denied  { read } for  pid=2454 comm="systemd-sysctl" name="20-printk.conf" dev="tmpfs" ino=27667 scontext=system_u:system_r:systemd_sysctl_t:s0 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=file permissive=0

Should we update the policy to allow systemd-sysctl to read var_run_t or update the policy such that files created under /run/sysctl.d get a different file content by default?

$ rpm -qa | grep selinux
selinux-policy-targeted-3.14.5-28.fc32.noarch
libselinux-3.0-3.fc32.x86_64
selinux-policy-3.14.5-28.fc32.noarch
libselinux-utils-3.0-3.fc32.x86_64
python3-libselinux-3.0-3.fc32.x86_64
rpm-plugin-selinux-4.15.1-2.fc32.1.x86_64

[zpytela]

@dustymabe, files in /run/sysctl.d are not generic runtime files, but it is questionable which context is the right one according to the current policy state:

# matchpathcon /etc/sysctl.conf /etc/sysctl.d/a.conf /usr/lib/sysctl.d/a.conf
/etc/sysctl.conf        system_u:object_r:system_conf_t:s0
/etc/sysctl.d/a.conf    system_u:object_r:etc_t:s0
/usr/lib/sysctl.d/a.conf        system_u:object_r:lib_t:s0

I am just afraid that changing context for all of them to match can make troubles.

[dustymabe]

Is there anyone that would know better that we could ask?

[dustymabe]

@zpytela - should we ask Lukas or Dan maybe?

[wrabcak]

Hi @dustymabe ,

If you relabel /run/sysctl.d to etc_t - # chcon -t etc_t /run/sysctl.d/

It should fix your issue.

Do you have existing bugzilla ticket for this issue?