Package: dracut-install
Version: 106-5
Severity: normal

I used a system running SE Linux to upgrade a removable device in a chroot
environment that is configured without SE Linux.  This is one of many uses of
containers etc on SE Linux that are not uncommon.  When it built the initrd
as part of configuring the kernel package saw the following output:

cp: setting attribute 'security.selinux' for 'security.selinux': Permission denied
dracut-install: ERROR: 'cp --reflink=auto --sparse=auto --preserve=mode,xattr,timestamps,ownership -fL /lib/modules/6.12.20-amd64/kernel/drivers/infiniband/core/ib_uverbs.ko.xz /var/tmp/mkinitramfs_T4zuE4/lib/modules/6.12.20-amd64/kernel/drivers/infiniband/core/ib_uverbs.ko.xz' failed with 1
dracut-install: dracut_install '/lib/modules/6.12.20-amd64/kernel/drivers/infiniband/core/ib_uverbs.ko.xz' '/lib/modules/6.12.20-amd64/kernel/drivers/infiniband/core/ib_uverbs.ko.xz' ERROR
cp: setting attribute 'security.selinux' for 'security.selinux': Permission denied
dracut-install: ERROR: 'cp --reflink=auto --sparse=auto --preserve=mode,xattr,timestamps,ownership -fL /lib/modules/6.12.20-amd64/kernel/drivers/infiniband/hw/mlx4/mlx4_ib.ko.xz /var/tmp/mkinitramfs_T4zuE4/lib/modules/6.12.20-amd64/kernel/drivers/infiniband/hw/mlx4/mlx4_ib.ko.xz' failed with 1
/etc/kernel/postinst.d/zz-update-grub:
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.12.20-amd64
Found initrd image: /boot/initrd.img-6.12.20-amd64
Found linux image: /boot/vmlinuz-6.1.0-32-amd64
Found initrd image: /boot/initrd.img-6.1.0-32-amd64
Found memtest86+ 64bit EFI image: /boot/memtest86+x64.efi
Found memtest86+ 32bit EFI image: /boot/memtest86+ia32.efi
Found memtest86+ 64bit image: /boot/memtest86+x64.bin
Found memtest86+ 32bit image: /boot/memtest86+ia32.bin
Adding boot menu entry for UEFI Firmware Settings ...
done
root@xev:/# echo $?
0

So that was regarded as successful and the errors were ignored.

Here's an example of similar operations:

root@xev:/# cp --reflink=auto --sparse=auto --preserve=mode,xattr,timestamps,ownership -fL /root/.bashrc /var/tmp
cp: setting attribute 'security.selinux' for 'security.selinux': Permission denied
root@xev:/# echo $?
1
root@xev:/# cp --reflink=auto --sparse=auto --preserve=mode,timestamps,ownership -fL /root/.bashrc /var/tmp
root@xev:/# echo $?
0

So the operation that causes the error was causing cp to return 1 - which is
apparently not treated as a noteworthy error!

Is there any case where preserving xattrs in an initramfs image is useful?
For the case of SE Linux the initramfs is discarded before SE Linux is
activated.

Having cp errors ignored is a bad idea as this could potentially result in
igoring something that makes the system fail to boot.

I think that xattrs should not be preserved in cp operations for this and
that cp errors should result in the process aborting.

There's the option DRACUT_NO_XATTR which for e.g. can be used in
dracut.conf.d/no-xattr/50-no-xattr.conf

export DRACUT_NO_XATTR=1

Please check if this helps.

There's the option DRACUT_NO_XATTR which for e.g. can be used in
dracut.conf.d/no-xattr/50-no-xattr.conf

export DRACUT_NO_XATTR=1

Please check if this helps.

Was also about to open a bug for dracut-install when running SELinux in enforcing mode, when I saw this one that looked eerily similar.

My scenario here doesn’t involve any chroot, it’s just a straight box running SEL enforced and with unattended upgrades enabled. As and when a new kernel comes in, the unattended-upgrades-dpkg.log shows another one of these lines for every kernel module being copied:

	cp: preserving permissions for '/var/tmp/mkinitramfs_DK9EQh/lib/modules/6/12/94+deb13-amd64/kernel/drivers/scsi/scsi_mod.ko.xz': Permission denied
	dracut-install: ERROR: 'cp --reflink=auto --sparse=auto --preserve=mode,xattr,timestamps.ownership -fL /lib/modules/6/12/94+deb13-amd64/kernel/drivers/scsi/scsi_mod.ko.xz' ERROR

The same errors will also appear if you install a new kernel interactively without doing a setenforce 0 first (but we don't have capture for those 😊). The module files themselves are successfully copied, but as the error suggests not all of the attributes might be preserved. It doesn't *seem* to have caused any problems so far, but you never know...

grepping through the audit log for the corresponding cp command comes up with the following type enforcement rule basically saying dracut (as bootloader_t) need setattr privs on kernel modules (modules_object_t) in addition to the read/write/etc. privs it already has;

	grep -I cp /var/log/audit/audit.log*|audit2allow

	#============ bootloader_t ============
	allow bootloader_t modules_object_t:file setattr;

As a workaround for the time being I'm adding the above TE config to a custom SEL module to permit this behaviour (basically an expanded version of the above);

	grep -I cp /var/log/audit/audit.log*|audit2allow -m dracut_xattr

	module dracut_xattr 1.0;

	require {
		type modules_object_t;
		type bootloader_t;
		class file setattr;
	}

	#============ bootloader_t ============
	allow bootloader_t modules_object_t:file setattr;

I dare say that setting DRACUT_NO_XATTR=1 will also function as a workaround for this, but IME the correct fix is to make sure that the type enforcement to allow setattr on modules is added to the base SELinux policy for dracut.

-------------------------------
G-RESEARCH believes the information provided herein is reliable. While every care has been taken to ensure accuracy, the information is furnished to the recipients with no warranty as to the completeness and accuracy of its contents and on condition that any errors or omissions shall not be made the basis of any claim, demand or cause of action.
The information in this email is intended only for the named recipient.  If you are not the intended recipient please notify us immediately and do not copy, distribute or take action based on this e-mail.
All messages sent to and from this e-mail address will be logged by G-RESEARCH and are subject to archival storage, monitoring, review and disclosure. For information about how G-RESEARCH uses your personal data, please refer to our Privacy Policy.
G-RESEARCH is the trading name of Alastair LLP and its affiliates globally. Alastair LLP is a limited liability partnership registered in England with number OC451515 and registered office 8th Floor One Soho Place, London, W1D 3BG.