Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionOndrej Mosnacek
2022-05-24 13:21:36 UTC
The check_ext_changes flag was intended to ensure that the policy is rebuilt from the current store content, while minimizing the work in case the module content matches (i.e. at least policy.linked can be assumed to be correct already). On a higher level, the goal was to allow to efficiently rebuild the policy during CoreOS/OSTree update process, where the conflict resolution may leave some policy files unchanged when the user has made any customizations.
However, the testing was focused on the case where a user has a local policy module installed, and failed to check that changing booleans also works correctly with this flag used by OSTree, which it indeed doesn't.
To fix this, we need to change semanage_direct_commit() to set do_write_kernel unconditionally when sh->check_ext_changes is set. Then the step to combine policy.linked with the boolean/other dbs into policy.kern (and update /etc/selinux/.../policy/policy.XX) will be always taken and the policy correctly refreshed. This will also change the semantics slightly and the --rebuild-if-modules-changed semodule's switch name will no longer fit, so renaming of it will also be in order (keeping the old name for a while as an alias for compatibility).
To reproduce (assumes fix for BZ 2057497 is in place):
1. Install RHCOS/Fedora CoreOS.
2. Change some boolean using setsebool -P.
3. Update some SELinux policy package (e.g. selinux-policy or container-selinux) and reboot.
4. Check the policy that is loaded and in /etc/selinux/.../policy - both will be the same as before the update.
Expected behavior is that after the update the binary policy contains both the user's boolean tweaks and the updated policy module content from the new packages.
(I'm assigning this to myself to fix it upstream, then I'll switch back to default assignee once the fix is available to do the actual backport.)
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (libsemanage bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2022:7804