search

OSInside / kiwi

KIWI - Appliance Builder Next Generation
https://osinside.github.io/kiwi
GNU General Public License v3.0
282 stars 142 forks source link

Files from /boot lack SELinux attributes #2568

Closed sbraz closed 2 weeks ago

sbraz commented 3 weeks ago

Problem description

Hi, The official Rocky Linux 9.4 image created by kiwi has missing SELinux attributes on a lot of files inside /boot/

[root@packer ~]# getfattr --absolute-names -d -m - /boot/grub2/i386-pc/config.h
[root@packer ~]# find /boot/ -print0 | while IFS= read -r -d '' i; do getfattr --absolute-names -d -m - $i | grep security.selinux -Fq || echo "$i";done | head
/boot/grub2/i386-pc
/boot/grub2/i386-pc/config.h
/boot/grub2/i386-pc/gdb_grub
/boot/grub2/i386-pc/gmodule.pl
/boot/grub2/i386-pc/kernel.exec
/boot/grub2/i386-pc/lnxboot.image
/boot/grub2/i386-pc/acpi.mod
/boot/grub2/i386-pc/adler32.mod
/boot/grub2/i386-pc/affs.mod
/boot/grub2/i386-pc/afs.mod
[…]

On the other hand, these files have the attributes:

[root@packer-output-d133a31b-a774-4ecb-9cf6-48b5b514e536 ~]# getfattr --absolute-names -d -m - /boot/efi/EFI/BOOT/BOOTX64.EFI
# file: /boot/efi/EFI/BOOT/BOOTX64.EFI
security.selinux="system_u:object_r:dosfs_t:s0"

[root@packer ~]# find /boot/ -print0 | while IFS= read -r -d '' i; do getfattr --absolute-names -d -m - $i | grep security.selinux -Fq && echo "$i";done | head
/boot/
/boot/symvers-5.14.0-427.18.1.el9_4.x86_64.gz
/boot/efi
/boot/efi/EFI
/boot/efi/EFI/BOOT
/boot/efi/EFI/BOOT/BOOTX64.EFI
/boot/efi/EFI/BOOT/fbx64.efi
/boot/efi/EFI/BOOT/grub.cfg
/boot/efi/EFI/BOOT/grubx64.efi
/boot/efi/EFI/BOOT/mmx64.efi

This causes the following command to fail because the target of the copy is created with SELinux attributes and rsync attempts to remove them to replicate the state of the source file:

[root@packer ~]# rsync -X /boot/grub2/i386-pc/config.h /test
rsync: [receiver] rsync_xal_set: lremovexattr("/.test.FBbUpd","security.selinux") failed: Permission denied (13)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1330) [sender=3.2.3]

Expected behaviour

Files under /boot should have SELinux attributes set.

Steps to reproduce

Copied from @NeilHanlon's message in https://github.com/OSInside/kiwi/issues/2553#issuecomment-2130330681

  1. git clone --branch fresh-empanadas https://git.resf.org/sig_core/toolkit.git

  2. pushd toolkit/iso/empanadas && poetry install

  3. poetry run build-image --version 9 --type GenericCloud --variant Base --debug

(last step will checkout the rocky kiwi descriptions as well as the mock config needed into /tmp)

OS and Software information

KIWI version: 10.0.16 Operating system host version: Rocky Linux 9 (via mock) Operating system target version: Rocky Linux 9.4 Open Build Service version (N/A if not using OBS): N/A Koji version (N/A if not using Koji): N/A

schaefi commented 3 weeks ago

Hmm, no idea so far. Maybe a question. In the kiwi bootloader code there is an rsync of grub modules into the /boot space. You can see this in the log with something like

[  147s] [ DEBUG   ]: 10:17:51 | --> Found in: /usr/src/packages/KIWI-oem/build/image-root/usr/lib/grub/i386-pc
[  147s] [ DEBUG   ]: 10:17:51 | EXEC: [rsync -a --exclude /*.module /usr/src/packages/KIWI-oem/build/image-root/usr/lib/grub/i386-pc/ /usr/src/packages/KIWI-oem/build/image-root/boot/grub2/i386-pc]

This copies the grub modules from /usr/lib/grub/... to /boot, but this action happens after setfiles was called on all the files that gets copied. So if a file in location A has the fattr and gets copied to location B does this require a new setfiles call ?

If yes this would explain it

nazunalika commented 3 weeks ago

Looking at the images, this is what I see:

[root@router images]# qemu-nbd --connect /dev/nbd2 Rocky-9-GenericCloud-Base-9.4-20240609.0.x86_64.qcow2
[root@router images]# mount /dev/nbd2p3 /mnt
[root@router images]# cd /mnt
[root@router mnt]# ls -laZ
total 167024
drwxr-xr-x.  5 root root system_u:object_r:boot_t:s0           4096 Jun  8 20:48 .
dr-xr-xr-x. 19 root root system_u:object_r:root_t:s0            252 Nov 20  2021 ..
lrwxrwxrwx.  1 root root system_u:object_r:unlabeled_t:s0         1 Jun  8 20:48 boot -> .
-rw-r--r--.  1 root root system_u:object_r:boot_t:s0         223212 May 27 09:47 config-5.14.0-427.18.1.el9_4.x86_64
drwx------.  2 root root system_u:object_r:boot_t:s0              6 May 21  2022 efi
drwx------.  7 root root system_u:object_r:boot_t:s0            111 Jun  8 20:48 grub2
-rw-------.  1 root root system_u:object_r:boot_t:s0       67737996 Jun  8 20:46 initramfs-0-rescue-251988954ff340a1bb6ee67a6e80aeb0.img
-rw-------.  1 root root system_u:object_r:unlabeled_t:s0  67196288 Jun  8 20:47 initramfs-5.14.0-427.18.1.el9_4.x86_64.img
drwxr-xr-x.  3 root root system_u:object_r:boot_t:s0             21 Jun  8 20:45 loader
-rw-rw-r--.  1 root root system_u:object_r:boot_t:s0             11 Jun  8 20:47 mbrid
lrwxrwxrwx.  1 root root system_u:object_r:boot_t:s0             52 Jun  8 20:45 symvers-5.14.0-427.18.1.el9_4.x86_64.gz -> /lib/modules/5.14.0-427.18.1.el9_4.x86_64/symvers.gz
-rw-------.  1 root root system_u:object_r:system_map_t:s0  8632572 May 27 09:47 System.map-5.14.0-427.18.1.el9_4.x86_64
-rwxr-xr-x.  1 root root system_u:object_r:boot_t:s0       13609800 Jun  8 20:46 vmlinuz-0-rescue-251988954ff340a1bb6ee67a6e80aeb0
-rwxr-xr-x.  1 root root system_u:object_r:boot_t:s0       13609800 May 27 09:47 vmlinuz-5.14.0-427.18.1.el9_4.x86_64
-rw-r--r--.  1 root root system_u:object_r:boot_t:s0            167 May 27 09:46 .vmlinuz-5.14.0-427.18.1.el9_4.x86_64.hmac
[root@router mnt]# cd grub2/
fonts/      i386-pc/    locale/     themes/     x86_64-efi/
[root@router mnt]# cd grub2/i386-pc/
[root@router i386-pc]# ls -laZ | head
total 3932
drwxr-xr-x. 2 root root system_u:object_r:unlabeled_t:s0  20480 Jun  8 20:48 .
drwx------. 7 root root system_u:object_r:boot_t:s0         111 Jun  8 20:48 ..
-rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0  13284 Jun  8 20:48 acpi.mod
-rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0   1492 Jun  8 20:48 adler32.mod
-rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0   7120 Jun  8 20:48 affs.mod
-rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0   9012 Jun  8 20:48 afs.mod
-rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0   1880 Jun  8 20:48 afsplitter.mod
-rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0  21580 Jun  8 20:48 ahci.mod
-rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0    492 Jun  8 20:48 all_video.mod
[root@router i386-pc]# cd ../x86_64-efi/
[root@router x86_64-efi]# ls -laZ | head
total 6168
drwxr-xr-x. 2 root root system_u:object_r:unlabeled_t:s0   8192 Jun  8 20:45 .
drwx------. 7 root root system_u:object_r:boot_t:s0         111 Jun  8 20:48 ..
-rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0  23216 May  1 14:27 acpi.mod
-rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0   2296 May  1 14:27 adler32.mod
-rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0  11984 May  1 14:27 affs.mod
-rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0  13224 May  1 14:27 afs.mod
-rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0   2864 May  1 14:27 afsplitter.mod
-rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0  37224 May  1 14:27 ahci.mod
-rw-r--r--. 1 root root system_u:object_r:unlabeled_t:s0    704 May  1 14:27 all_video.mod

I see a lot of unlabeled files, which is unusual, given that when they're in /boot, they're supposed to be at least boot_t. Even the initramfs file there being unlabeled is odd. That is a file I would not expect to be touched by kiwi as that is deployed by the kernel-core package. That shouldn't be happening. A restorecon/fixfiles fixes the labels as expected.

# confirming the contexts
[root@test ~]# grep '^/boot' /etc/selinux/targeted/contexts/files/file_contexts
/boot/.*        system_u:object_r:boot_t:s0
/boot/a?quota\.(user|group)     --      system_u:object_r:quota_db_t:s0
/boot/efi(/.*)?/System\.map(-.*)?       --      system_u:object_r:system_map_t:s0
/boot/System\.map(-.*)? --      system_u:object_r:system_map_t:s0
/boot/lost\+found/.*    <<none>>
/boot   system_u:object_r:boot_t:s0
/boot/\.journal <<none>>
/boot/lost\+found       -d      system_u:object_r:lost_found_t:s0
/boot/device-credentials        --      system_u:object_r:fdo_device_credentials_t:s0

# restoring the contexts
[root@test ~]# restorecon -v /boot/initramfs-5.14.0-427.18.1.el9_4.x86_64.img
Relabeled /boot/initramfs-5.14.0-427.18.1.el9_4.x86_64.img from system_u:object_r:unlabeled_t:s0 to system_u:object_r:boot_t:s0
[root@test ~]# restorecon -v /boot/grub2/i386-pc/acpi.mod
Relabeled /boot/grub2/i386-pc/acpi.mod from system_u:object_r:unlabeled_t:s0 to system_u:object_r:boot_t:s0

This copies the grub modules from /usr/lib/grub/... to /boot, but this action happens after setfiles was called on all the files that gets copied. So if a file in location A has the fattr and gets copied to location B does this require a new setfiles call ?

If yes this would explain it

A copy should not require a new setfiles/fixfiles/restorecon. On a running system, doing a copy of a file does not carry its prior attributes. Files are not typically unlabeled, also.

[root@xmpp01 etc]# ls -lZ fstab
-rw-r--r--. 1 root root system_u:object_r:etc_t:s0 1130 Mar 13 12:12 fstab
[root@xmpp01 etc]# cp /etc/fstab /tmp

# below shows that file inherits the label of its location as it was a simple copy
[root@xmpp01 etc]# ls -laZ /tmp/fstab
-rw-r--r--. 1 root root unconfined_u:object_r:user_tmp_t:s0 1130 Jun 11 11:43 /tmp/fstab

However, performing a mv, cp --preserve=all, or rsync -X will carry the attributes.

[root@xmpp01 etc]# rm /tmp/fstab
rm: remove regular file '/tmp/fstab'? y
[root@xmpp01 etc]# cp --preserve=all /etc/fstab /tmp
[root@xmpp01 etc]# ls -laZ /tmp/fstab
-rw-r--r--. 1 root root system_u:object_r:etc_t:s0 1130 Mar 13 12:12 /tmp/fstab
[root@xmpp01 etc]# rm /tmp/fstab
rm: remove regular file '/tmp/fstab'? y
[root@xmpp01 etc]# mv /etc/fstab /tmp/
[root@xmpp01 etc]# ls -laZ /tmp/fstab
-rw-r--r--. 1 root root system_u:object_r:etc_t:s0 1130 Mar 13 12:12 /tmp/fstab
[root@xmpp01 etc]# mv /tmp/fstab /etc/
[root@xmpp01 etc]# rsync -X /etc/fstab /tmp/
[root@xmpp01 etc]# ls -laZ /tmp/fstab
-rw-r--r--. 1 root root system_u:object_r:etc_t:s0 1130 Jun 11 11:45 /tmp/fstab
schaefi commented 2 weeks ago

Thanks for the details. ok so for the initramfs kiwi has to re-create the initrd because the kernel package provided one is not necessarily suitable according to the image configuration, e.g missing dracut modules, missing tools, or keys, or settings to be available in the initrd, etc. Thus if you look into the kiwi log file you should see something like this:

[   89s] [ INFO    ]: 02:39:32 | Processing SELinux file security contexts
[   89s] [ DEBUG   ]: 02:39:32 | EXEC: [chroot /usr/src/packages/KIWI-oem/build/image-root setfiles --help]
[   89s] [ DEBUG   ]: 02:39:32 | EXEC: [chroot /usr/src/packages/KIWI-oem/build/image-root setfiles -F -p -c /etc/selinux/targeted/policy/policy.33 -e /proc -e 
/sys -e /dev /etc/selinux/targeted/contexts/files/file_contexts /]

...

[  108s] [ DEBUG   ]: 02:39:51 | EXEC: [chroot /usr/src/packages/KIWI-oem/build/image-root dracut --verbose --no-hostonly --no-hostonly-cmdline --install /.profile --add  kiwi-repart  --omit  multipath  --install /config.partids kiwi-test-image-live-disk.x86_64-2.0.0.initrd 6.8.11-200.fc39.x86_64]
...
[  141s] [ DEBUG   ]: 02:40:24 | EXEC: [mv /usr/src/packages/KIWI-oem/build/image-root/kiwi-test-image-live-disk.x86_64-2.0.0.initrd /usr/src/packages/KIWI-oem]
[  141s] [ INFO    ]: 02:40:24 | --> initrd archive as initramfs-6.8.11-200.fc39.x86_64.img
[  141s] [ DEBUG   ]: 02:40:24 | EXEC: [mv /usr/src/packages/KIWI-oem/kiwi-test-image-live-disk.x86_64-2.0.0.initrd /usr/src/packages/KIWI-oem/build/image-root/boot/initramfs-6.8.11-200.fc39.x86_64.img]

...

[  142s] [ DEBUG   ]: 02:40:25 | EXEC: [rsync -a --exclude /*.module /usr/src/packages/KIWI-oem/build/image-root/usr/lib/grub/i386-pc/ /usr/src/packages/KIWI-oem/build/image-root/boot/grub2/i386-pc]

So according to what you wrote that creation of data caused the unlabeled files to exist there. The reason is that the setfiles call happens early (in second 89) and there is other code that drops data to /boot which is not covered by that setfiles call.

I'll take a look and make sure that we label everything

schaefi commented 2 weeks ago

@nazunalika I have a patch ready, looking at the labels I get

[root@fedora grub2]# ls -laZ
total 64
drwx------. 7 root root system_u:object_r:boot_t:s0   111 Jun 17 16:13 .
dr-xr-xr-x. 5 root root system_u:object_r:boot_t:s0  4096 Jun 17 16:13 ..
drwx------. 2 root root system_u:object_r:boot_t:s0    25 Jun 17 16:11 fonts
-rw-------. 1 root root system_u:object_r:boot_t:s0 12307 Jun 17 16:13 grub.cfg
-rw-r--r--. 1 root root system_u:object_r:boot_t:s0  1024 Jun 17 16:13 grubenv
drwxr-xr-x. 2 root root system_u:object_r:boot_t:s0 20480 Jun 17 16:13 i386-pc
drwxr-xr-x. 2 root root system_u:object_r:boot_t:s0  4096 Jun 17 16:13 locale
drwxr-xr-x. 3 root root system_u:object_r:boot_t:s0    20 Jun 17 15:19 themes
drwxr-xr-x. 2 root root system_u:object_r:boot_t:s0  8192 Jun 17 16:11 x86_64-efi

That looks better ;) will create a PR

NeilHanlon commented 2 weeks ago

Thank you @schaefi , @Conan-Kudo ! We will update and test :)