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

travier · 2024-07-31T10:44:47Z

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

The text was updated successfully, but these errors were encountered:

travier · 2024-07-31T11:04:01Z

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

travier · 2024-07-31T11:14:30Z

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?

travier · 2024-07-31T11:16:51Z

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.

HuijingHei · 2024-07-31T13:52:28Z

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

cgwalters · 2024-07-31T13:56:17Z

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

travier · 2024-07-31T15:53:59Z

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.

cgwalters · 2024-07-31T16:55:35Z

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.

cgwalters · 2024-07-31T16:59:27Z

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.

travier · 2024-07-31T17:23:13Z

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.

travier · 2024-07-31T17:24:06Z

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

achilleas-k · 2024-08-01T14:45:17Z

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

achilleas-k · 2024-08-01T14:55:38Z

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.

jlebon · 2024-08-22T20:54:32Z

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.

travier · 2024-08-26T11:21:01Z

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

jlebon · 2024-08-28T17:00:01Z

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

yasminvalim · 2024-08-28T18:38:00Z

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

dustymabe · 2024-09-06T20:01:01Z

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?

dustymabe · 2024-09-06T20:07:56Z

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.

/boot/efi and /sysroot dir and subfiles are unlabeled_t since 40.20240504.3.0. This is likely due to a missing step in the OSBuild pipeline as this started with coreos/fedora-coreos-tracker#1653. This should be removed after the next barrier release, if the newly produced images are fixed. See coreos/fedora-coreos-tracker#1771 And coreos/fedora-coreos-tracker#1772

dustymabe · 2024-09-10T14:32:37Z

opened osbuild/osbuild#1877 to discuss further a fix in osbuild itself.

achilleas-k · 2024-09-13T10:29:58Z

Expanding a bit from the issue Dusty linked to:

The core of the issue, as I understand it, is that with the way the image is built, the filesystem mountpoints on the parent filesystem (in this case /boot/efi on /boot, i.e. the node itself when /boot/efi is not mounted) are never labelled because they're never "exposed" during setfiles or copying. This isn't a problem usually because mountpoints at build time and at runtime are always hidden by the mounted filesystem itself.

This is a problem for the CoreOS image because /boot/efi isn't mounted on boot (as Dusty clearly described above). I assume the reason this wasn't an issue before osbuild is because /boot/efi was created "in place", so to speak. The build scripts were creating the OS tree directly, and creating /boot/efi on an selinux enabled system will apply the labels/contexts for that path on creation (am I getting this right?). On the other hand osbuild is running mkdir /some/runtime/mountpoint/boot/efi before mounting the EFI filesystem to copy files into it (no labelling).

I don't know if this should be considered a bug in osbuild or something the image definition itself should take care of. We could certainly make it easier to do what's needed with mechanisms in osbuild, but I wouldn't make it an implicit action (e.g. applying labels automatically when mkdiring mountpoints).

We have a limitation now in the selinux stage, it wont run setfiles on a mounted tree, but that's an easy fix. With that, I would leave it up to the image definition to do the right thing with the tooling, for example:

Create disk (truncate)
Partition disk (sfdisk)
Create filesystems (mkfs)
NEW: Create mountpoints on each filesystem separately (mkdir)
NEW: Apply selinux labels to each filesystem mountpoint (setfiles)

Step 5 is the important step. It can be done explicitly:

{
  "type": "org.osbuild.selinux",
  "options": {
    "labels": {
      "/efi": "<labels for /boot/efi>"
    }
  },
  "mounts": [ "mount /boot filesystem at <mount root>" ],
  "devices": { disk device }
}

or implicitly with a full relabeling (better long term):

{
  "type": "org.osbuild.selinux",
  "options": {
    "file_contexts": "etc/selinux/targeted/contexts/files/file_contexts"
  },
  "mounts": [
    "mount / filesystem at <mount root>",
    "mount /boot filesystem at <mount root>/boot"
  ],
  "devices": { disk device }
}

Generalising this isn't really something that fits into osbuild itself, it's a piece of logic that belongs in the image definition or a manifest generator like osbuild-mpp and osbuild/images. But osbuild's selinux stage should support the workflow.

dustymabe · 2024-09-16T20:45:44Z

replied over in osbuild/osbuild#1877 (comment)

We have a few issues right now where files in our images don't have any selinux context (i.e. end up unlabeled_t). Here we workaround the hidden mountpoints issue [1] with a patch to OSBuild to hardcode some chcon calls. We workaround the "bunch of files under /sysroot are unlabeled" issue [2] by backported a proposed upstream change to the org.osbuild.selinux stage [3] and then using it to explicitly set the context on the root of the tree to `root_t`. We also add a fix [4] for another issue where '/boot/coreos/platforms.json' would end up with the wrong label. [1] coreos/fedora-coreos-tracker#1771 [2] coreos/fedora-coreos-tracker#1772 [3] osbuild/osbuild#1889 [4] osbuild/osbuild#1888

dustymabe · 2024-09-23T14:30:25Z

The first part of this (fix/workaround in images) was delivered in coreos/coreos-assembler#3885

The second part of this (fixing existing systems on upgrade with a migration script) will be done in coreos/fedora-coreos-config#3150

Tests will be added to confirm no unlabeled or mislabeled files exist in coreos/fedora-coreos-config#3172

/boot/efi and /sysroot dir and subfiles are unlabeled_t since 40.20240504.3.0. This is likely due to some missing scaffolding in the OSBuild software and definitions that we started using in [1]. These issues [2] [3] were addressed in [4] for new image builds, but we still need to fix upgrading systems, which we do here in this migration script. Note that we also fix a few files in /boot that were left unlabeled by `rdcore` [5] while we are in here. [1] coreos/fedora-coreos-tracker#1653. [2] coreos/fedora-coreos-tracker#1771 [3] coreos/fedora-coreos-tracker#1772 [4] coreos/coreos-assembler#3885 [5] coreos/fedora-coreos-tracker#1770 Co-authored-by: Dusty Mabe <dusty@dustymabe.com>

We have a few issues right now where files in our images don't have any selinux context (i.e. end up unlabeled_t). Here we workaround the hidden mountpoints issue [1] with a patch to OSBuild to hardcode some chcon calls. We workaround the "bunch of files under /sysroot are unlabeled" issue [2] by backported a proposed upstream change to the org.osbuild.selinux stage [3] and then using it to explicitly set the context on the root of the tree to `root_t`. We also add a fix [4] for another issue where '/boot/coreos/platforms.json' would end up with the wrong label. [1] coreos/fedora-coreos-tracker#1771 [2] coreos/fedora-coreos-tracker#1772 [3] osbuild/osbuild#1889 [4] osbuild/osbuild#1888 (cherry picked from commit d3302e0)

travier added kind/bug area/selinux labels Jul 31, 2024

travier mentioned this issue Jul 31, 2024

Switch to using OSBuild for most CoreOS boot image building #1653

Closed

travier added the rawhide Issues that uniquely pertain to rawhide label Jul 31, 2024

travier changed the title ~~/boot/efi is unlabeled_t since version (to be determined)~~ /boot/efi is unlabeled_t since version 40.20240504.3.0 Jul 31, 2024

travier mentioned this issue Jul 31, 2024

tracker: Fedora 41 changes considerations #1714

Open

travier mentioned this issue Aug 20, 2024

Missing SELinux rules (was: Empty bootupctl status since 0.2.20) coreos/bootupd#694

Open

jlebon added the meeting topics for meetings label Aug 22, 2024

jlebon mentioned this issue Aug 28, 2024

/sysroot dir and subfiles are unlabeled_t since version 40.20240504.3.0 #1772

Open

travier mentioned this issue Aug 28, 2024

Extend bootupd test to include testing adoption and updates #1788

Open

travier added the jira for syncing to jira label Sep 3, 2024

travier mentioned this issue Sep 3, 2024

Revert to permissive for coreos-installer & bootupd fedora-selinux/selinux-policy#2257

Open

dustymabe mentioned this issue Sep 3, 2024

/sysroot and /boot/efi have unlabeled_t selinux labels openshift/os#1599

Open

jbtrystram removed the meeting topics for meetings label Sep 4, 2024

dustymabe mentioned this issue Sep 5, 2024

coreos-boot-edit.sh creates /boot/.root_uuid as unlabeled_t #1770

Open

jbtrystram mentioned this issue Sep 9, 2024

overlay.d: add 07fix-selinux-labels overlay coreos/fedora-coreos-config#3150

Open

dustymabe mentioned this issue Sep 10, 2024

incorrect selinux file contexts on mountpoints in created disk images osbuild/osbuild#1877

Open

dustymabe mentioned this issue Sep 17, 2024

workaround selinux issues with osbuild coreos/coreos-assembler#3885

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

travier commented Jul 31, 2024 •

edited

Loading

travier commented Jul 31, 2024

travier commented Jul 31, 2024

travier commented Jul 31, 2024

HuijingHei commented Jul 31, 2024

cgwalters commented Jul 31, 2024

travier commented Jul 31, 2024 •

edited

Loading

cgwalters commented Jul 31, 2024

cgwalters commented Jul 31, 2024

travier commented Jul 31, 2024

travier commented Jul 31, 2024

achilleas-k commented Aug 1, 2024

achilleas-k commented Aug 1, 2024 •

edited

Loading

jlebon commented Aug 22, 2024

travier commented Aug 26, 2024 •

edited

Loading

jlebon commented Aug 28, 2024

yasminvalim commented Aug 28, 2024

dustymabe commented Sep 6, 2024

dustymabe commented Sep 6, 2024

dustymabe commented Sep 10, 2024

achilleas-k commented Sep 13, 2024 •

edited

Loading

dustymabe commented Sep 16, 2024

dustymabe commented Sep 23, 2024 •

edited

Loading

/boot/efi is unlabeled_t since version 40.20240504.3.0 #1771

/boot/efi is unlabeled_t since version 40.20240504.3.0 #1771

Comments

travier commented Jul 31, 2024 • edited Loading

Describe the bug

Reproduction steps

Expected behavior

Actual behavior

System details

Butane or Ignition config

Additional information

travier commented Jul 31, 2024

travier commented Jul 31, 2024

travier commented Jul 31, 2024

HuijingHei commented Jul 31, 2024

cgwalters commented Jul 31, 2024

travier commented Jul 31, 2024 • edited Loading

cgwalters commented Jul 31, 2024

cgwalters commented Jul 31, 2024

travier commented Jul 31, 2024

travier commented Jul 31, 2024

achilleas-k commented Aug 1, 2024

achilleas-k commented Aug 1, 2024 • edited Loading

jlebon commented Aug 22, 2024

travier commented Aug 26, 2024 • edited Loading

jlebon commented Aug 28, 2024

yasminvalim commented Aug 28, 2024

dustymabe commented Sep 6, 2024

dustymabe commented Sep 6, 2024

dustymabe commented Sep 10, 2024

achilleas-k commented Sep 13, 2024 • edited Loading

dustymabe commented Sep 16, 2024

dustymabe commented Sep 23, 2024 • edited Loading

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

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

travier commented Jul 31, 2024 •

edited

Loading

travier commented Jul 31, 2024 •

edited

Loading

achilleas-k commented Aug 1, 2024 •

edited

Loading

travier commented Aug 26, 2024 •

edited

Loading

achilleas-k commented Sep 13, 2024 •

edited

Loading

dustymabe commented Sep 23, 2024 •

edited

Loading