Revert to permissive for coreos-installer & bootupd #2257
Conversation
|
I have no objection for this, maybe should exclude But there are existing bugs for bootupd and coreos-installer:
|
travier
force-pushed
the
rawhide-permissive-coreos
branch
from
5e689be
to
9927041
Compare
travier
changed the title
|
For the record I still generally don't think it's a valuable effort to confine bootupd or coreos-installer. |
|
@zpytela Can you take a look at this? Otherwise, we'll likely have to set them back to permissive downstream in the CoreOS configs until the associated bugs are fixed. (Note also since this bug was opened, branching happened, so this needs to be fixed in both rawhide and f41.) |
|
For coreos-installer, https://bugzilla.redhat.com/show_bug.cgi?id=2305385 is the one for Fedora. |
Recent changes in the SELinux policy have broken a lot of our code. Revert the affected domains back to permissive mode until fedora-selinux/selinux-policy#2257 merges and the domains are reverted back to permissive mode upstream. bootupd_t: https://bugzilla.redhat.com/show_bug.cgi?id=2300306 coreos_installer_t: https://bugzilla.redhat.com/show_bug.cgi?id=2305385
Recent changes in the SELinux policy have broken a lot of our code. Revert the affected domains back to permissive mode until fedora-selinux/selinux-policy#2257 merges and the domains are reverted back to permissive mode upstream. bootupd_t: https://bugzilla.redhat.com/show_bug.cgi?id=2300306 coreos_installer_t: https://bugzilla.redhat.com/show_bug.cgi?id=2305385
I agree as well that we should not confine those tools. I tried to argue that in:
@zpytela Could you point us to the exact rule mentioned in #2145 (comment) so that we could explain why this does not apply here / is not needed? |
|
#2336 should help with bootupd, but we still have coreos/fedora-coreos-tracker#1771 blocking us on Fedora CoreOS so we still might need to make it permissive for F41. |
Recent changes in the SELinux policy have broken a lot of our code. Revert the affected domains back to permissive mode so we can continue to build and test `releasever >= 41` until fedora-selinux/selinux-policy#2257 merges and the domains are reverted upstream or until the issue is resolved altogether.
Recent changes in the SELinux policy have broken a lot of our code. Revert the affected domains back to permissive mode so we can continue to build and test `releasever >= 41` until fedora-selinux/selinux-policy#2257 merges and the domains are reverted upstream or until the issue is resolved altogether. Add the workaround for `afterburn_t` as well so we can unblock coreos/fedora-coreos-tracker#1784
Recent changes in the SELinux policy have broken a lot of our code. Revert the affected domains back to permissive mode so we can continue to build and test `releasever >= 41` until fedora-selinux/selinux-policy#2257 merges and the domains are reverted upstream or until the issue is resolved altogether. Add the workaround for `afterburn_t` as well so we can unblock coreos/fedora-coreos-tracker#1784
Recent changes in the SELinux policy have broken a lot of our code. Revert the affected domains back to permissive mode so we can continue to build and test `releasever >= 41` until fedora-selinux/selinux-policy#2257 merges and the domains are reverted upstream or until the issue is resolved altogether. Add the workaround for `afterburn_t` as well so we can unblock coreos/fedora-coreos-tracker#1784
|
The coreos installer generators are permissive since 2024-07-15, can I see some fresh report? |
|
|
We turned We had to do it for Fedora CoreOS as well: https://github.com/coreos/fedora-coreos-config/blob/testing-devel/manifests/selinux-workaround.yaml It would be good to merge this one here until we get all the issues resolved again. |
Temporarily revert to permissive for those domains so that we have time to fix the issues that we missed earlier.
Revert "Remove permissive domain for bootupd_t"
This reverts commit 0cbc7da.
Revert "Remove permissive domain for coreos_installer_t"
This reverts commit cd99e90.