Missing SELinux labeling on some files when built on SELinux-disabled hosts

[mvo5]

While experimenting with bootc install to-filesystem for the bib work I noticed that on firstboot the /boot directory and partiton is not mounted:

[root@localhost ~]# ls -a /boot/
.  ..
[root@localhost ~]# cat /etc/fstab 
UUID=a22006db-c737-4eb2-9a35-50edad5832ba /boot auto ro 0 0
[root@localhost ~]# mount|grep boot
[root@localhost ~]# 

I looked a bit into this but it seems an fedora:eln issue, I see /boot mounted just fine on quay.io/centos-bootc/centos-bootc-dev:stream9.

Feel free to close as not-actionable/irrelevant for bootc as it appears to be an image issue but I reported it because we talked about it and I wanted to followup properly.

[cgwalters]

I'm not immediately reproducing this with a full bootc install to-disk --via-loopback flow, using quay.io/centos-bootc/fedora-bootc@sha256:4ebdf0663d5ca87204ef5b7c45bd1ac17567094813d7568aac8cc576a974c228.

[mvo5]

I'm sorry, I should have digged deeper. It seems it's fallout from using BOOTC_SKIP_SELINUX_HOST_CHECK, /etc/fstab is unlabeld in my image because the image was generated on a non-selinux system:

[root@localhost ~]# ls -lZ /etc/fstab 
-rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0 60 Feb 27 08:13 /etc/fstab

root@localhost ~]# journalctl |grep -i denied
Feb 27 08:18:15 localhost kernel: audit: type=1400 audit(1709021894.847:4): avc:  denied  { read } for  pid=464 comm="systemd-fstab-g" name="fstab" dev="sda4" ino=299109 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0
Feb 27 08:18:14 localhost systemd-fstab-generator[464]: Failed to open /etc/fstab: Permission denied
Feb 27 08:18:15 localhost audit[499]: AVC avc:  denied  { write } for  pid=499 comm="systemd-journal" name="var" dev="sda4" ino=259088 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=dir permissive=0
Feb 27 08:18:15 localhost audit[550]: AVC avc:  denied  { create } for  pid=550 comm="systemd-random-" name="random-seed" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=file permissive=0

and indeed

[root@localhost ~]# chcon -t etc_t /etc/fstab 
[root@localhost ~]# ls -lZ /etc/fstab 
-rw-r--r--. 1 root root system_u:object_r:etc_t:s0 60 Feb 27 08:13 /etc/fstab
[root@localhost ~]# reboot
...
[root@localhost ~]# ls /boot/
boot  bootupd-state.json  efi  grub2  loader  loader.1	lost+found  ostree
[root@localhost ~]#

For the "old" ostree stages we have a org.osbuild.ostree.selinux stage that will fixup the selinux labels, it essentially run:

[root@localhost etc]# setfiles -F -r /path/to/deployment-tree /sysroot/ostree/deploy/default/deploy/95eb9b0c05473ba8acdbd417cec2c4603a836dbd94250a5a455c270fb100c2ce.0/etc/selinux/targeted/contexts/files/file_contexts /etc

But that won't work of course because the deployment is unlabled and osbuild no longer touches things after bootc isntall to-filesystem ran.

[root@localhost sysroot]# ls -lZ /sysroot/ostree/deploy/default/deploy/95eb9b0c05473ba8acdbd417cec2c4603a836dbd94250a5a455c270fb100c2ce.0/etc/fstab
-rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0 60 Feb 27 08:13 /sysroot/ostree/deploy/default/deploy/95eb9b0c05473ba8acdbd417cec2c4603a836dbd94250a5a455c270fb100c2ce.0/etc/fstab

A very naive approach might be to just label it with something like:

diff --git a/lib/src/install.rs b/lib/src/install.rs
index c017821..2ca2f18 100644
--- a/lib/src/install.rs
+++ b/lib/src/install.rs
@@ -621,6 +621,9 @@ async fn initialize_ostree_root_from_self(
     }
     f.flush()?;
 
+    let fstab_path = rootfs.join("etc/fstab");
+    state.lsm_label(&fstab_path, "/etc/fstab".into(), false)?;
+
     if let Some(contents) = state.root_ssh_authorized_keys.as_deref() {
         osconfig::inject_root_ssh_authorized_keys(&root, contents)?;
     }

but it feels a bit crude (sorry!).

[cgwalters]

Ah. Yes that patch looks fine. I suspect the root ssh authorized keys would need similar treatment. Or maybe what would be best is to actually lower down into ostree something like ostree admin selinux-relabel (with equivalent api) that would relabel etc and var in the deployment.

(Or of course, put all this stuff behind something more like #267 which would handle this in a slightly more structured fashion)