bootupd
bootupd copied to clipboard
Missing SELinux rules (was: Empty `bootupctl status` since 0.2.20)
On a fresh Fedora Silverblue Rawhide installation:
root@fedora:~# bootupctl status
Running as unit: bootupd.service
This is likely due to something we missed in https://github.com/coreos/bootupd/pull/663.
We should likely call systemd-run with --pty or --pipe: https://www.freedesktop.org/software/systemd/man/latest/systemd-run.html#--pty
Hum, we already are using --pipe, so looks like something else is not working as expected.
Looks like we also need --service-type=oneshot
~~and --remain-after-exit~~. Not this one, we would habe to stop /reset it every time.
If for whatever reason the previous command fails, then I need to systemctl reset-failed before calling bootupd again.
root@fedora:~# systemd-run --unit bootupd --property=MountFlags=slave --service-type=oneshot --pipe bootupctl status
Running as unit: bootupd.service
root@fedora:~# systemd-run --unit bootupd --property=MountFlags=slave --service-type=oneshot --pty bootupctl status
Running as unit: bootupd.service; invocation ID: c111d0e1cebe4401bb89af4cfa5358f1
Press ^] three times within 1s to disconnect TTY.
root@fedora:~# systemd-run --unit bootupd --property=MountFlags=slave --service-type=oneshot --pty bootupctl status
Failed to start transient service unit: Unit bootupd.service was already loaded or has a fragment file.
root@fedora:~# systemctl status bootupd.service
× bootupd.service - /usr/bin/bootupctl status
Loaded: loaded (/run/systemd/transient/bootupd.service; transient)
Transient: yes
Drop-In: /usr/lib/systemd/system/service.d
└─10-timeout-abort.conf
Active: failed (Result: signal) since Mon 2024-07-29 16:46:17 CEST; 14s ago
Invocation: c111d0e1cebe4401bb89af4cfa5358f1
Process: 4624 ExecStart=/usr/bin/bootupctl status (code=killed, signal=HUP)
Main PID: 4624 (code=killed, signal=HUP)
Mem peak: 3M
CPU: 32ms
Jul 29 16:46:17 fedora systemd[1]: Starting bootupd.service - /usr/bin/bootupctl status...
Jul 29 16:46:17 fedora systemd[1]: bootupd.service: Main process exited, code=killed, status=1/HUP
Jul 29 16:46:17 fedora systemd[1]: bootupd.service: Failed with result 'signal'.
Jul 29 16:46:17 fedora systemd[1]: Failed to start bootupd.service - /usr/bin/bootupctl status.
root@fedora:~# systemd-run --unit bootupd --property=MountFlags=slave --service-type=oneshot --pty bootupctl status
Failed to start transient service unit: Unit bootupd.service was already loaded or has a fragment file.
Ah, I think I understand now. We need to --wait for the unit to start and terminate. Might need --quiet as well.
Hum, I still don't get any output with:
systemd-run --unit bootupd --property=MountFlags=slave --service-type=oneshot --pipe --wait --quiet -- bootupctl status
and using --pty makes it fail with SIGHUP.
No such issue on fcos-rawhide 41.20240720.91.0
[root@cosa-devsh ~]# bootupctl status
Running as unit: bootupd.service
Component BIOS
Installed: grub2-tools-1:2.06-124.fc41.x86_64
Update: At latest version
Component EFI
Installed: grub2-efi-x64-1:2.06-124.fc41.x86_64,shim-x64-15.8-3.x86_64
Update: At latest version
No components are adoptable.
CoreOS aleph version: 41.20240720.91.0
Boot method: EFI
[root@cosa-devsh ~]# rpm-ostree status
State: idle
Deployments:
● ostree-remote-image:fedora:docker://quay.io/fedora/fedora-coreos:rawhide
Digest: sha256:a96de6e7fb733d8db53a126c6829a5c2d881d92c9eb3c646b60a694b5dfc2f41
Version: 41.20240720.91.0 (2024-07-20T12:47:28Z)
One likely notable difference is that Fedora CoreOS Rawhide still uses systemd 255.
Might be https://github.com/systemd/systemd/pull/32917
Hit this when do testing for https://bugzilla.redhat.com/show_bug.cgi?id=2300306, with upgrade selinux to selinux-policy-41.10-1.20240729144215211154.pr2271.13.g8bed6eac7.fc40.noarch.
Set selinux to permissive to run setenforce 0, then the output looks good, so the root cause might be https://github.com/fedora-selinux/selinux-policy/commit/0cbc7da8130fd7cf030ab61f68a3eb449a8d6391
semanage permissive -a bootupd_t gets me the status back on Silverblue 41.
Ugh...I knew the selinux policy would break a ton of things, we should never have done that.
Test with latest selinux-policy, bootupctl status works, but still have selinux avc denied log
[root@cosa-devsh ~]# bootupctl status
Running as unit: bootupd.service
Component BIOS
Installed: grub2-tools-1:2.12-4.fc41.x86_64
Update: At latest version
Component EFI
Installed: grub2-efi-x64-1:2.12-4.fc41.x86_64,shim-x64-15.8-3.x86_64
Update: At latest version
No components are adoptable.
Boot method: EFI
[root@cosa-devsh ~]# rpm -q bootupd
bootupd-0.2.20-2.fc41.x86_64
[root@cosa-devsh ~]# rpm -q selinux-policy
selinux-policy-41.14-1.fc41.noarch
[root@cosa-devsh ~]# ausearch -m avc
----
time->Mon Aug 19 14:14:21 2024
type=AVC msg=audit(1724076861.158:158): avc: denied { search } for pid=2129 comm="bootupctl" name="/" dev="vda4" ino=128 scontext=system_u:system_r:bootupd_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=0
That's likely https://github.com/coreos/fedora-coreos-tracker/issues/1771
Looks like this has been fixed in the SELinux policy that landed in F41.
I spoke too soon, I can still see some issues on Silverblue:
type=AVC msg=audit(1725290040.770:429): avc: denied { getattr } for pid=4524 comm="bootupctl" path="/boot/efi/EFI/BOOT/BOOTIA32.EFI" dev="vda1" ino=142 scontext=system_u:system_r:bootupd_t:s0 tcontext=system_u:object_r:dosfs_t:s0 tclass=file permissive=1
type=AVC msg=audit(1725290040.770:430): avc: denied { read } for pid=4524 comm="bootupctl" name="BOOTIA32.EFI" dev="vda1" ino=142 scontext=system_u:system_r:bootupd_t:s0 tcontext=system_u:object_r:dosfs_t:s0 tclass=file permissive=1
type=AVC msg=audit(1725290040.770:431): avc: denied { open } for pid=4524 comm="bootupctl" path="/boot/efi/EFI/BOOT/BOOTIA32.EFI" dev="vda1" ino=142 scontext=system_u:system_r:bootupd_t:s0 tcontext=system_u:object_r:dosfs_t:s0 tclass=file permissive=1
type=AVC msg=audit(1725290040.862:432): avc: denied { read } for pid=4524 comm="bootupctl" name="EFI" dev="vda1" ino=113 scontext=system_u:system_r:bootupd_t:s0 tcontext=system_u:object_r:dosfs_t:s0 tclass=dir permissive=1
type=AVC msg=audit(1725290040.863:433): avc: denied { write } for pid=4524 comm="bootupctl" path=2F626F6F742F233234202864656C6574656429 dev="vda2" ino=24 scontext=system_u:system_r:bootupd_t:s0 tcontext=system_u:object_r:boot_t:s0 tclass=file permissive=1
type=AVC msg=audit(1725290040.869:434): avc: denied { link } for pid=4524 comm="bootupctl" name="#24" dev="vda2" ino=24 scontext=system_u:system_r:bootupd_t:s0 tcontext=system_u:object_r:boot_t:s0 tclass=file permissive=1
type=AVC msg=audit(1725290040.869:435): avc: denied { rename } for pid=4524 comm="bootupctl" name=".tmp.X84SiQFG.tmp" dev="vda2" ino=24 scontext=system_u:system_r:bootupd_t:s0 tcontext=system_u:object_r:boot_t:s0 tclass=file permissive=1
Filed: https://github.com/fedora-selinux/selinux-policy/issues/2334
Part 2 in https://github.com/fedora-selinux/selinux-policy/issues/2341
Freeze exception for F41: https://bugzilla.redhat.com/show_bug.cgi?id=2309742
Part 3 in https://github.com/fedora-selinux/selinux-policy/issues/2362
Looks like fixes has just been merged in the policy. We'll have to wait for a build and test this again.
This should be fixed with selinux-policy-41.26-1.fc41.
Verify selinux-policy-41.26-1.fc41 on fedora-coreos-41.20241124.20.0-qemu.x86_64.qcow2, the issue is fixed.
[root@cosa-devsh core]# rpm -q selinux-policy
selinux-policy-41.26-1.fc41.noarch
[core@cosa-devsh ~]$ sudo bootupctl status
Running as unit: bootupd.service
Component BIOS
Installed: grub2-tools-1:2.12-10.fc41.x86_64
Update: Available: grub2-tools-1:2.12-13.fc41.x86_64
Component EFI
Installed: grub2-efi-x64-1:2.12-10.fc41.x86_64,shim-x64-15.8-3.x86_64
Update: Available: grub2-efi-x64-1:2.12-13.fc41.x86_64,shim-x64-15.8-3.x86_64
No components are adoptable.
CoreOS aleph version: 41.20241109.2.0
Boot method: EFI
[root@cosa-devsh ~]# bootupctl update
Running as unit: bootupd.service
Previous BIOS: grub2-tools-1:2.12-10.fc41.x86_64
Updated BIOS: grub2-tools-1:2.12-13.fc41.x86_64
Previous EFI: grub2-efi-x64-1:2.12-10.fc41.x86_64,shim-x64-15.8-3.x86_64
Updated EFI: grub2-efi-x64-1:2.12-13.fc41.x86_64,shim-x64-15.8-3.x86_64
[root@cosa-devsh ~]# ausearch -m avc
<no matches>
[root@cosa-devsh ~]# bootupctl status
Running as unit: bootupd.service
Component BIOS
Installed: grub2-tools-1:2.12-13.fc41.x86_64
Update: At latest version
Component EFI
Installed: grub2-efi-x64-1:2.12-13.fc41.x86_64,shim-x64-15.8-3.x86_64
Update: At latest version
No components are adoptable.
CoreOS aleph version: 41.20241109.2.0
Boot method: EFI
[root@cosa-devsh ~]# mount -o remount,rw /boot
[root@cosa-devsh ~]# rm /boot/bootupd-state.json
[root@cosa-devsh ~]# bootupctl update
Running as unit: bootupd.service
Adopted and updated: BIOS: grub2-tools-1:2.12-13.fc41.x86_64
Adopted and updated: EFI: grub2-efi-x64-1:2.12-13.fc41.x86_64,shim-x64-15.8-3.x86_64
[root@cosa-devsh ~]# bootupctl status
Running as unit: bootupd.service
Component BIOS
Installed: grub2-tools-1:2.12-13.fc41.x86_64
Update: At latest version
Component EFI
Installed: grub2-efi-x64-1:2.12-13.fc41.x86_64,shim-x64-15.8-3.x86_64
Update: At latest version
No components are adoptable.
CoreOS aleph version: 41.20241109.2.0
Boot method: EFI
[root@cosa-devsh ~]# ausearch -m avc
<no matches>
Also verify passed on Silverblue 41.20241126.0.
fedora@fedora:~$ rpm-ostree status
State: idle
Deployments:
● fedora:fedora/41/x86_64/silverblue
Version: 41.20241126.0 (2024-11-26T00:38:46Z)
BaseCommit: 8f1a689e1a2a833d4e8ca17b4682d13551290435ff5ec920a529fd305b675f47
GPGSignature: Valid signature by 466CF2D8B60BC3057AA9453ED0622462E99D6AD1
LocalOverrides: bootupd 0.2.24-1.fc41 -> 0.2.25-1.fc41
fedora:fedora/41/x86_64/silverblue
Version: 41.20241121.0 (2024-11-21T03:10:35Z)
BaseCommit: dc7f3ffdfe61b3ff6df6e0f0a69c16a8a783851c1e07cc6d37a25bbb23aae4a7
GPGSignature: Valid signature by 466CF2D8B60BC3057AA9453ED0622462E99D6AD1
LocalOverrides: bootupd 0.2.24-1.fc41 -> 0.2.25-1.fc41
fedora@fedora:~$ sudo semanage permissive -l | grep bootupd_t
fedora@fedora:~$ sudo rm -f /boot/bootupd-state.json
fedora@fedora:~$ sudo bootupctl update
Running as unit: bootupd.service
Adopted and updated: EFI: grub2-efi-ia32-1:2.12-13.fc41.x86_64,grub2-efi-x64-1:2.12-13.fc41.x86_64,shim-ia32-15.8-3.x86_64,shim-x64-15.8-3.x86_64
fedora@fedora:~$ sudo bootupctl status
Running as unit: bootupd.service; invocation ID: d2330a801d95434bb4253672fbe20f3d
Component EFI
Installed: grub2-efi-ia32-1:2.12-13.fc41.x86_64,grub2-efi-x64-1:2.12-13.fc41.x86_64,shim-ia32-15.8-3.x86_64,shim-x64-15.8-3.x86_64
Update: At latest version
No components are adoptable.
Boot method: EFI
fedora@fedora:~$ sudo ausearch -m avc -ts 02:00
<no matches>
Close this the issue is fixed.
Great! Thanks!