`/boot/efi` is `unlabeled_t` since version 40.20240504.3.0

Question

`/boot/efi` is `unlabeled_t` since version 40.20240504.3.0

travier opened this issue 3 months ago · 22 comments

travier commented 3 months ago

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

Answer 1 · 2024-07-31T11:04:01.000Z

As 40.20240504.3.0 is the first bad version, this points to #1653 introducing this issue.

Answer 2 · 2024-07-31T11:14:30.000Z

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?

Answer 3 · 2024-07-31T11:16:51.000Z

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.

Answer 4 · 2024-07-31T13:52:28.000Z

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

Answer 5 · 2024-07-31T13:56:17.000Z

This is another one that would get fixed once FCOS rebases on Fedora bootc, because bootc gets this correct.

Answer 6 · 2024-07-31T15:53:59.000Z

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.

Answer 7 · 2024-07-31T16:55:35.000Z

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.

Answer 8 · 2024-07-31T16:59:27.000Z

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.

Answer 9 · 2024-07-31T17:23:13.000Z

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.

Answer 10 · 2024-07-31T17:24:06.000Z

We'll still have to work on a script to locally fix existing installations.

Answer 11 · 2024-08-01T14:45:17.000Z

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"
    }
}

Answer 12 · 2024-08-01T14:55:38.000Z

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.

Answer 13 · 2024-08-22T20:54:32.000Z

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.

Answer 14 · 2024-08-26T11:21:01.000Z

Note that we'll need to keep this workaround fixup script until we've fixed our osbuild pipeline / boot images.

Answer 15 · 2024-08-28T17:00:01.000Z

When fixing this, we should also fix #1772 in the same barrier code.

Answer 16 · 2024-08-28T18:38:00.000Z

We discussed this in our community meeting today. You can review the details of our discussion here.

Answer 17 · 2024-09-06T20:01:01.000Z

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?

Answer 18 · 2024-09-06T20:07:56.000Z

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.