Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
travier opened this issue Jul 29, 2024 · 20 comments
Open

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

travier opened this issue Jul 29, 2024 · 20 comments
Labels
bug Something isn't working jira For syncing with Jira

Comments

@travier
Copy link
Member

travier commented Jul 29, 2024

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
Copy link
Member Author

travier commented Jul 29, 2024

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

@travier
Copy link
Member Author

travier commented Jul 29, 2024

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

@travier
Copy link
Member Author

travier commented Jul 29, 2024

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

@travier
Copy link
Member Author

travier commented Jul 29, 2024

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
Copy link
Member Author

travier commented Jul 29, 2024

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

@travier
Copy link
Member Author

travier commented Jul 29, 2024

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
Copy link
Member

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
Copy link
Member Author

travier commented Jul 29, 2024

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

@travier
Copy link
Member Author

travier commented Jul 29, 2024

Might be systemd/systemd#32917

@HuijingHei
Copy link
Member

HuijingHei commented Jul 31, 2024

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
Copy link
Member Author

travier commented Jul 31, 2024

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

@cgwalters
Copy link
Member

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

@HuijingHei
Copy link
Member

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
Copy link
Member Author

travier commented Aug 20, 2024

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

@travier
Copy link
Member Author

travier commented Sep 2, 2024

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

@travier travier closed this as completed Sep 2, 2024
@travier travier reopened this Sep 2, 2024
@travier
Copy link
Member Author

travier commented Sep 2, 2024

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
Copy link
Member Author

travier commented Sep 2, 2024

Filed: fedora-selinux/selinux-policy#2334

travier pushed a commit to coreos/fedora-coreos-config that referenced this issue Sep 3, 2024
@travier travier added jira For syncing with Jira bug Something isn't working labels Sep 3, 2024
@travier
Copy link
Member Author

travier commented Sep 3, 2024

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

@travier travier changed the title Empty bootupctl status since 0.2.20 Missing SELinux rules (was: Empty bootupctl status since 0.2.20) Sep 3, 2024
@travier
Copy link
Member Author

travier commented Sep 4, 2024

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

@HuijingHei
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working jira For syncing with Jira
Projects
None yet
Development

No branches or pull requests

3 participants