`/boot/efi` is `unlabeled_t` since version 40.20240504.3.0
travier opened this issue · 22 comments
Describe the bug
/boot/efi
is unlabeled_t
since 40.20240504.3.0.
Bisect results:
- 40.20240416.3.1 is good
- 40.20240504.3.0 is bad
- 40.20240519.3.0 is bad
- 40.20240616.3.0 is bad
Reproduction steps
Boot FCOS. Run:
ls -alhZ /boot
Expected behavior
/boot/efi
is correctly labeled as boot_t
(unmounted) and dosfs_t
(mounted).
Actual behavior
/boot/efi
is unlabeled_t
(unmounted).
System details
N/A
Butane or Ignition config
None
Additional information
This is impacting us in Rawhide as the bootupd_t SELinux domain is no longer permissive there: https://bugzilla.redhat.com/show_bug.cgi?id=2300306
As 40.20240504.3.0 is the first bad version, this points to #1653 introducing this issue.
Looks like the SELinux label is missing in https://github.com/coreos/coreos-assembler/blob/main/src/osbuild-manifests/coreos.osbuild.x86_64.mpp.yaml#L164..L168 maybe?
Looks like there is no option for it in https://github.com/osbuild/osbuild/blob/main/stages/org.osbuild.mkdir.meta.json. I could only find https://github.com/osbuild/osbuild/blob/main/stages/org.osbuild.selinux.meta.json but that's too broad.
And files under /sysroot
are unlabeled_t
, /sysroot/.aleph-version.json
and /sysroot/.coreos-aleph-version.json
are created by https://github.com/osbuild/osbuild/blob/main/stages/org.osbuild.ostree.aleph#L102
[root@cosa-devsh ~]# ls -alZ /sysroot/
total 8
drwxr-xr-x. 4 root root system_u:object_r:unlabeled_t:s0 93 Aug 1 2022 .
drwxr-xr-x. 12 root root system_u:object_r:root_t:s0 4096 Jul 29 18:54 ..
-rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0 206 Aug 1 2022 .aleph-version.json
lrwxrwxrwx. 1 root root system_u:object_r:unlabeled_t:s0 19 Aug 1 2022 .coreos-aleph-version.json -> .aleph-version.json
drwxr-xr-x. 2 root root system_u:object_r:unlabeled_t:s0 6 Jul 29 18:54 boot
drwxr-xr-x. 5 root root system_u:object_r:unlabeled_t:s0 62 Jul 31 13:46 ostree
This is another one that would get fixed once FCOS rebases on Fedora bootc, because bootc gets this correct.
How so? Is something done in https://github.com/osbuild/bootc-image-builder to account for that? This also wasn't an issue before we moved to osbuild so I think we missed something there.
How so? Is something done in https://github.com/osbuild/bootc-image-builder to account for that?
Conceptually, the role of osbuild with bootc is just to set up the partitions and an empty filesystem, and invoke bootc install to-filesystem
, which is what I want anaconda to do as well with rhinstaller/anaconda#5197
This takes over a lot of the role of all the currently split-up micro "stages" in osbuild. See for example the giant discussion of a custom aleph stage. Instead, that's just hardcoded in bootc, osbuild is not involved.
The simplest way to say it is the bootc vision is that the container image and container technology is the center of gravity, the north star, the default source of truth, the technological heart. If you want to change how the bootloader gets installed, you change the contents of the container - not some external tool.
So that would be using https://github.com/osbuild/osbuild/blob/main/stages/org.osbuild.bootc.install-to-filesystem. That could be a future improvement / unification point for the osbuild part.
We'll still have to work on a script to locally fix existing installations.
As a general rule, it's a good idea to add an selinux stage at the end of each pipeline in osbuild. This isn't really necessary for pipelines that finalise a disk image (like a qcow conversion pipeline), but for anything that installs or changes files that will end up on the disk, an org.osbuild.selinux
stage at the end of the pipeline will apply all selinux labels in the tree based on the contexts from the tree itself:
{
"type": "org.osbuild.selinux",
"options": {
"file_contexts": "etc/selinux/targeted/contexts/files/file_contexts"
}
}
Ok, I see there's already an org.osbuild.ostree.selinux
stage here:
https://github.com/coreos/coreos-assembler/blob/main/src/osbuild-manifests/coreos.osbuild.x86_64.mpp.yaml#L244-L247
But the partitions aren't mounted for that stage, so perhaps that's what's missing. The selinux stage is fixing all the labels in the tree, but /boot
isn't mounted so it wont change /boot/efi
.
AIUI, the situation currently is that:
- nodes born on new enough f40 has missing labels, but bootupd still works because the
bootupd_t
policy is permissive - nodes born on f41+ has missing labels, and bootupd doesn't work because the
bootupd_t
policy is no longer permissive
So one path forward is to:
- Fix the labeling in new disk images, definitely before f41 hits
next
. - Do a barrier release with a script that fixes unlabeled directories on affected machines. At the latest this barrier release needs to be before the rebase to f41, but could be before. We do already do a barrier release during rebases, so could combine it.
Note that we'll need to keep this workaround fixup script until we've fixed our osbuild pipeline / boot images.
We discussed this in our community meeting today. You can review the details of our discussion here.
I don't think this problem is specific to us. Here is a RHEL 10 candidate image rhel-guest-image.qcow2
:
[root@localhost ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 30G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 200M 0 part /boot/efi
└─sda3 8:3 0 29.8G 0 part /
sr0 11:0 1 368K 0 rom
[root@localhost ~]#
[root@localhost ~]#
[root@localhost ~]# ls -ldZ /boot/efi
drwx------. 3 root root system_u:object_r:dosfs_t:s0 16384 Dec 31 1969 /boot/efi
[root@localhost ~]# umount /boot/efi
[root@localhost ~]# ls -ldZ /boot/efi
drwxr-xr-x. 2 root root system_u:object_r:unlabeled_t:s0 6 Sep 6 04:33 /boot/efi
and here is Fedora 40 IoT (from the raw disk image):
[root@localhost ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
zram0 251:0 0 3.8G 0 disk [SWAP]
vda 252:0 0 4G 0 disk
├─vda1 252:1 0 501M 0 part /boot/efi
├─vda2 252:2 0 1G 0 part /boot
└─vda3 252:3 0 2.5G 0 part /var
/sysroot/ostree/deploy/fedora-iot/var
/usr
/etc
/
/sysroot
[root@localhost ~]# ls -ldZ /boot /boot/efi
drwxr-xr-x. 7 root root system_u:object_r:boot_t:s0 4096 Apr 22 20:11 /boot
drwx------. 3 root root system_u:object_r:dosfs_t:s0 16384 Jan 1 1970 /boot/efi
[root@localhost ~]# umount /boot/efi
[root@localhost ~]# ls -ldZ /boot/efi
drwxr-xr-x. 2 root root system_u:object_r:unlabeled_t:s0 4096 Apr 22 20:11 /boot/efi
@achilleas-k I don't really think there is a way to get the labels correct on the root of a mounted filesystem today using OSBuild is there?
It's also worth noting I doubt other editions observe a problem because (I think) we are the only ones that default to not having /boot/efi
mounted on boot.