Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
dustymabe opened this issue Oct 4, 2024 · 6 comments
Open

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

dustymabe opened this issue Oct 4, 2024 · 6 comments
Assignees
@HuijingHei
Labels
jira for syncing to jira

Comments

@dustymabe
Copy link
Member

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 dustymabe mentioned this issue Oct 4, 2024
Merged
@HuijingHei HuijingHei self-assigned this Oct 8, 2024
@jmarrero jmarrero added the jira for syncing to jira label Oct 8, 2024
@dustymabe
Copy link
Member Author

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member

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 added a commit to cgwalters/ostree that referenced this issue Oct 18, 2024
@cgwalters
deploy: Don't copy xattrs for devicetree
14e4ae4 
xref: coreos/fedora-coreos-tracker#1808

For the kernel/initramfs that we copy to `/boot`
we use an explicit relabeling today, ignoring the source SELinux
context.

When we added handling for devicetree it reuse the `copy_dir_recurse`
we have for `etc` handling, and that copied the source xattrs.

Let's ensure that the devicetree is also `boot_t` by *not* copying
xattrs and relying on the default labeling.

Signed-off-by: Colin Walters <[email protected]>
@cgwalters cgwalters mentioned this issue Oct 18, 2024
Open
@cgwalters
Copy link
Member

Put up ostreedev/ostree#3323

cgwalters added a commit to cgwalters/ostree that referenced this issue Oct 18, 2024
@cgwalters
deploy: Don't copy xattrs for devicetree
72202df 
xref: coreos/fedora-coreos-tracker#1808

For the kernel/initramfs that we copy to `/boot`
we use an explicit relabeling today, ignoring the source SELinux
context.

When we added handling for devicetree it reuse the `copy_dir_recurse`
we have for `etc` handling, and that copied the source xattrs.

Let's ensure that the devicetree is also `boot_t` by *not* copying
xattrs and relying on the default labeling.

Signed-off-by: Colin Walters <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@HuijingHei HuijingHei

Labels
jira for syncing to jira
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@cgwalters @jmarrero @dustymabe @HuijingHei