https://bugzilla.suse.com/show_bug.cgi?id=1224149 https://bugzilla.suse.com/show_bug.cgi?id=1224149#c8 Zdenek Kubala <zkubala@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zkubala@suse.com --- Comment #8 from Zdenek Kubala <zkubala@suse.com> --- (In reply to Alberto Planas Dominguez from comment #6)
I reproduced this issue. The problem is this: sdbootutil is adding a new snapper plugin in "/usr/lib/snapper/plugins/10-sdbootutil.snapper". This is a bash script that will be called by snapper when a new snapsot is created or removed, for example.
When a snapshot gets removed, the plugin this calls '/usr/bin/sdbootutil remove-all-kernels "$num"', to clean the kernel and the boot loader entries from the image.
If I execute the command from outside snapper, this works and the entry gets removed, but when is snapper the one that calls it, selinux complains.
To fully reproduce it from the sdboot image that is in https://build.opensuse.org/package/show/devel:microos:images/openSUSE-MicroO...
# After installation, install any package transactional-update pkg in emacs-nox
# Lets assume that this created a new transaction with id "2" snapper ls
# The new transaction should be the default, we switch back to "1" as default btrfs subvolume list -o /.snapshots btrfs subvolume set-default 258 /.snapshots
# Now we can remove the snapshot snapper rm 2
This last command will trigger the remove-all-kernels, that fails with:
bootctl unlink opensuse-microos-6.9.3-1-default-2.conf opensuse-microos-6.9.3-1-default-2.conf is the default boot entry Failed to remove "/boot/efi/loader/entries/opensuse-microos-6.9.3-1-default-2.conf": Permission denied
You can see in the selinux side this:
semodule -DB ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts boot
---- time->Wed Jun 5 20:04:56 2024 type=AVC msg=audit(1717610696.275:408): avc: denied { unlink } for pid=9576 comm="bootctl" name="opensuse-microos-6.9.3-1-default-2.conf" dev="vda2" ino=59 scontext=system_u:system_r:snapperd_t:s0 tcontext=system_u:object_r:dosfs_t:s0 tclass=file permissive=0
So snapper should have permissions to access bootctl or something like that
This AVC denial has been firstly reported in bsc#1224120 and I have been looking into that and also it can be reproduced even without TPM2 `systemd-pcrlock` and FDE. So I would keep it separated and this unlink AVC handle in bsc#1224120. -- You are receiving this mail because: You are on the CC list for the bug.