aarch64: upgrade causes SELinux mislabeled dtb files in /boot/ostree

[dustymabe]

On upgrades it appears files in dtb files in /boot on aarch64 systems have the wrong context. It looks like the context matches where the files are copied from rather than the paths they are being copied to.

When booted from the fresh 40.20240825.3.0 stable image (i.e. the release from a few weeks back):

Fedora CoreOS 40.20240825.3.0
[core@cosa-devsh ~]$
[core@cosa-devsh ~]$ sudo restorecon -vnr /boot/ostree/
[core@cosa-devsh ~]$

After upgrade to latest stable:

Fedora CoreOS 40.20240906.3.0
[core@cosa-devsh ~]$
[core@cosa-devsh ~]$ rpm-ostree status
State: idle
AutomaticUpdatesDriver: Zincati
  DriverState: active; periodically polling for updates (last checked Fri 2024-10-04 16:07:17 UTC)
Deployments:
_ fedora:fedora/aarch64/coreos/stable
                  Version: 40.20240906.3.0 (2024-09-23T18:11:19Z)
                   Commit: aad86a6390dbcf8caab4390e14854b2d6ddfa2b6885d5d3dfc7511bd431ba0ae
             GPGSignature: Valid signature by 115DF9AEF857853EE8445D0A0727707EA15B79CC

  fedora:fedora/aarch64/coreos/stable
                  Version: 40.20240825.3.0 (2024-09-10T00:49:47Z)
                   Commit: a0e2520be57c71a0d459fee831b1e9eb0f9aea02b4d05d2fe7b8f66b8678471a
             GPGSignature: Valid signature by 115DF9AEF857853EE8445D0A0727707EA15B79CC



[core@cosa-devsh ~]$ sudo restorecon -vnr /boot/ostree/ | wc -l
1866


[core@cosa-devsh ~]$ sudo restorecon -vnr /boot/ostree/ | head
Would relabel /boot/ostree/fedora-coreos-3bdd09e36aecabd4d88e93b696c885903cde80cbdadc32861bc59881a26cf953/dtb from system_u:object_r:modules_object_t:s0 to system_u:object_r:boot_t:s0
Would relabel /boot/ostree/fedora-coreos-3bdd09e36aecabd4d88e93b696c885903cde80cbdadc32861bc59881a26cf953/dtb/marvell from system_u:object_r:modules_object_t:s0 to system_u:object_r:boot_t:s0
Would relabel /boot/ostree/fedora-coreos-3bdd09e36aecabd4d88e93b696c885903cde80cbdadc32861bc59881a26cf953/dtb/marvell/cn9132-db-B.dtb from system_u:object_r:modules_object_t:s0 to system_u:object_r:boot_t:s0
Would relabel /boot/ostree/fedora-coreos-3bdd09e36aecabd4d88e93b696c885903cde80cbdadc32861bc59881a26cf953/dtb/marvell/armada-3720-uDPU.dtb from system_u:object_r:modules_object_t:s0 to system_u:object_r:boot_t:s0
Would relabel /boot/ostree/fedora-coreos-3bdd09e36aecabd4d88e93b696c885903cde80cbdadc32861bc59881a26cf953/dtb/marvell/cn9130-crb-B.dtb from system_u:object_r:modules_object_t:s0 to system_u:object_r:boot_t:s0
Would relabel /boot/ostree/fedora-coreos-3bdd09e36aecabd4d88e93b696c885903cde80cbdadc32861bc59881a26cf953/dtb/marvell/armada-7040-mochabin.dtb from system_u:object_r:modules_object_t:s0 to system_u:object_r:boot_t:s0
Would relabel /boot/ostree/fedora-coreos-3bdd09e36aecabd4d88e93b696c885903cde80cbdadc32861bc59881a26cf953/dtb/marvell/armada-3720-gl-mv1000.dtb from system_u:object_r:modules_object_t:s0 to system_u:object_r:boot_t:s0
Would relabel /boot/ostree/fedora-coreos-3bdd09e36aecabd4d88e93b696c885903cde80cbdadc32861bc59881a26cf953/dtb/marvell/armada-7040-db.dtb from system_u:object_r:modules_object_t:s0 to system_u:object_r:boot_t:s0
Would relabel /boot/ostree/fedora-coreos-3bdd09e36aecabd4d88e93b696c885903cde80cbdadc32861bc59881a26cf953/dtb/marvell/cn9131-db-B.dtb from system_u:object_r:modules_object_t:s0 to system_u:object_r:boot_t:s0
Would relabel /boot/ostree/fedora-coreos-3bdd09e36aecabd4d88e93b696c885903cde80cbdadc32861bc59881a26cf953/dtb/marvell/armada-3720-espressobin-v7-emmc.dtb from system_u:object_r:modules_object_t:s0 to system_u:object_r:boot_t:s0

So they are modules_object_t versus the policy expecting them to be boot_t. Not sure if this is a real problem or not.

Note I think this happens even on upgrades where there is no kernel update.

[dustymabe]

So they are modules_object_t versus the policy expecting them to be boot_t. Not sure if this is a real problem or not.

Another thing to note here. It may actually be correct that they are labeled modules_object_t and we need to update the SELinux policy (rather than updating our tools) to expect files in that location to have the modules_object_t label.

To state it a different way, the problem here is that these files don't match what the policy expects. The fix may be:

1. the policy needs to be updated
2. OR our tools need to copy the files differently

Which one of those options is the correct path? I don't know.

@jlebon @travier @jmarrero may know.

[HuijingHei]

It may actually be correct that they are labeled modules_object_t

Check on rhel9.4, the dtb files are labeled boot_t, maybe they should be boot_t instead of modules_object_t ?

[hhei@hhei-rhel-aarch ~]$ ls -alZ /boot/dtb
lrwxrwxrwx. 1 root root system_u:object_r:boot_t:s0 33 Sep 10 17:04 /boot/dtb -> dtb-5.14.0-427.33.1.el9_4.aarch64
[hhei@hhei-rhel-aarch ~]$ ls -alZ /boot/dtb/
total 20
...
drwxr-xr-x.  2 root root system_u:object_r:boot_t:s0 4096 Sep 10 17:04 qcom

[HuijingHei]

Run on rawhide, not sure it is the same as #1806 (comment), after run ostree admin finalize-staged, all the files (include old files) under /boot/ostree/fedora-coreos-*/dtb are relabeled with modules_object_t

root@hhei-fcos-aarch:/var/home/core# restorecon -rvn /boot/ostree/
root@hhei-fcos-aarch:/var/home/core# ls -aZld /boot/ostree/fedora-coreos-*/dtb
drwxr-xr-x. 19 root root system_u:object_r:boot_t:s0 1024 Aug  1  2022 /boot/ostree/fedora-coreos-e83a58b219990702b3f2fdbf78527e42988af8548a7f749495fce69f6622063b/dtb

root@hhei-fcos-aarch:/var/home/core# rpm-ostree upgrade
Pulling manifest: ostree-remote-image:fedora:docker://quay.io/fedora/fedora-coreos:rawhide
Importing: ostree-remote-image:fedora:docker://quay.io/fedora/fedora-coreos:rawhide (digest: sha256:2b735c0d7e9954730b03027eaa4f245e7949cc297d35d21ad90ca2ab31e72ea8)
ostree chunk layers already present: 29
ostree chunk layers needed: 22 (309.2 MB)
...
Staging deployment... done
Upgraded:
  docker-cli 27.3.1-1.fc42 -> 27.3.1-2.fc42
  moby-engine 27.3.1-1.fc42 -> 27.3.1-2.fc42
  moby-filesystem 27.3.1-1.fc42 -> 27.3.1-2.fc42
Added:
  pigz-2.8-5.fc41.aarch64
Run "systemctl reboot" to start a reboot

root@hhei-fcos-aarch:/var/home/core# /usr/bin/ostree admin finalize-staged
Copying /etc changes: 7 modified, 0 removed, 35 added
Bootloader updated; bootconfig swap: yes; bootversion: boot.0.1, deployment count change: 1

root@hhei-fcos-aarch:/var/home/core# ls -aZld /boot/ostree/fedora-coreos-*/dtb
drwxr-xr-x. 19 root root system_u:object_r:modules_object_t:s0 1024 Oct  8 12:12 /boot/ostree/fedora-coreos-de1ac6a148205a1840fdd98d996feb110df37d0113bf11c03ed0641d1fd5f9b4/dtb
drwxr-xr-x. 19 root root system_u:object_r:modules_object_t:s0 1024 Aug  1  2022 /boot/ostree/fedora-coreos-e83a58b219990702b3f2fdbf78527e42988af8548a7f749495fce69f6622063b/dtb

And do testing according to #1806 (comment), no lucky

root@hhei-fcos-aarch:/var/home/core# restorecon -rvn /boot/ostree/
root@hhei-fcos-aarch:/var/home/core# semodule -N --refresh
root@hhei-fcos-aarch:/var/home/core# restorecon -rvn /boot/ostree/

[dustymabe]

And do testing according to #1806 (comment), no lucky

yes. I think this issue is distinct from #1806 because that one ONLY affects rawhide right now

[HuijingHei]

And do testing according to #1806 (comment), no lucky

yes. I think this issue is distinct from #1806 because that one ONLY affects rawhide right now

You are right, thanks. I think your above comment makes sense to me, need to confirm.

[cgwalters]

Put up ostreedev/ostree#3323

[HuijingHei]

@dustymabe , the above PR is merged, can I close this now or hold until new ostree release (or backport the PR to rawhide/f41)?

[dustymabe]

@HuijingHei I would prefer to leave this open until the fix has made it into FCOS. Once the fix does land we can revert the dtb exception part of coreos/fedora-coreos-config#3192 I think.

or hold until new ostree release (or backport the PR to rawhide/f41)?

either one of those options works for me :)

[HuijingHei]

OK, then will do the backport, thanks!

[HuijingHei]

@dustymabe there is the new f41 build https://bodhi.fedoraproject.org/updates/FEDORA-2024-aea0210a8d which includes the fixed patch, should I add a fast-track in next-devel ? (And also remove the the dtb exception part in next-nevel branch)

[dustymabe]

We'll be promoting F41 to testing-devel today so let's wait and just fast-track to testing-devel instead (later today or tomorrow).

[dustymabe]

testing and next should have included this change in this week's releases:

ostree 2024.8-1.fc41.x86_64 → 2024.9-1.fc41.x86_64 

[dustymabe]

The fix for this went into next stream release 41.20241109.1.0. Please try out the new release and report issues.

[dustymabe]

The fix for this went into testing stream release 41.20241109.2.0. Please try out the new release and report issues.

[dustymabe]

The fix for this went into stable stream release 41.20241109.3.0.