Missing SELinux rules (was: Empty bootupctl status since 0.2.20)

[travier]

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 #663.

We should likely call systemd-run with --pty or --pipe: https://www.freedesktop.org/software/systemd/man/latest/systemd-run.html#--pty

[travier]

Hum, we already are using --pipe, so looks like something else is not working as expected.

[travier]

Looks like we also need --service-type=oneshot

[travier]

and --remain-after-exit. Not this one, we would habe to stop /reset it every time.

[travier]

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.

[travier]

Ah, I think I understand now. We need to --wait for the unit to start and terminate. Might need --quiet as well.

[travier]

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.

[HuijingHei]

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)

[travier]

One likely notable difference is that Fedora CoreOS Rawhide still uses systemd 255.

[travier]

Might be systemd/systemd#32917

[HuijingHei]

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 fedora-selinux/selinux-policy@0cbc7da

[travier]

semanage permissive -a bootupd_t gets me the status back on Silverblue 41.

[cgwalters]

Ugh...I knew the selinux policy would break a ton of things, we should never have done that.

[HuijingHei]

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

[travier]

That's likely coreos/fedora-coreos-tracker#1771

[travier]

Looks like this has been fixed in the SELinux policy that landed in F41.

[travier]

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

[travier]

Filed: fedora-selinux/selinux-policy#2334

[travier]

Part 2 in fedora-selinux/selinux-policy#2341

[travier]

Freeze exception for F41: https://bugzilla.redhat.com/show_bug.cgi?id=2309742

[HuijingHei]

Part 3 in fedora-selinux/selinux-policy#2362

[travier]

Looks like fixes has just been merged in the policy. We'll have to wait for a build and test this again.