Bug 2089802

Summary: libsemanage's check_ext_changes doesn't pick up boolean changes
Product: Red Hat Enterprise Linux 8 Reporter: Ondrej Mosnacek <omosnace>
Component: libsemanageAssignee: Vit Mojzis <vmojzis>
Status: CLOSED ERRATA QA Contact: Milos Malik <mmalik>
Severity: high Docs Contact:
Priority: medium    
Version: 8.6CC: dornelas, dustymabe, dwalsh, lucab, lvrabec, mmalik, plautrba, ssekidde, travier, tscherf, vmojzis
Target Milestone: rcKeywords: AutoVerified, Triaged, ZStream
Target Release: ---Flags: pm-rhel: mirror+
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: libsemanage-2.9-9.el8 Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of:
: 2104935 2129139 (view as bug list) Environment:
Last Closed: 2022-11-08 10:56:37 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2129139    

Description Ondrej 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.)

Comment 1 Ondrej Mosnacek 2022-06-08 17:30:56 UTC
Initial patch set posted upstream:
https://lore.kernel.org/selinux/20220608170954.114668-1-omosnace@redhat.com/T/

Comment 2 Ondrej Mosnacek 2022-07-01 07:22:33 UTC
The patches have been merged upstream:
https://github.com/SELinuxProject/selinux/commit/bdbe52be1bfbcc8a4614731f791d08ab8fb82ca2
https://github.com/SELinuxProject/selinux/commit/8cc529af51e8aa68a167ce78cf92687604f98619

Not sure if we want to backport also the second semodule patch that just renames the command-line option. It does keep the old name as an alias, so the ostree mechanism that uses it should keep working after the patch (I tested it before submitting the the patches).

Comment 3 Dusty Mabe 2022-07-01 14:08:21 UTC
My $.02. If we're doing a backport anyway might as well backport both patches so the calling code can be updated to use the new name faster.

Comment 25 errata-xmlrpc 2022-11-08 10:56:37 UTC
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