Restore selinux context when replacing config files

[jepio]

Description

Several ASB ModuleTest steps have started failing after the release of RHEL 9.5. Looking into them, I found that they are failing due to issues with selinux file contexts. The failure comes from chage when changing password expiration settings, after a previous rule modified /etc/shadow,/etc/shadow-,/etc/passwd,/etc/passwd-. With additional output from chage one can see the following:

[2024-11-26 09:00:27] [main.c:604] Step 3 of 16
[2024-11-26 09:00:27] [main.c:614] Running desired test 'SecurityBaseline.remediateEnsurePasswordExpiration'
[2024-11-26 09:00:27] [UserUtils.c:2400] EnsureUsersHaveDatesOfLastPasswordChanges: all users who have passwords have dates of last password changes
[2024-11-26 09:00:27] [UserUtils.c:2289] SetMaxDaysBetweenPasswordChanges: user 'cloudtest' (1001, 1001) has maximum time between password changes of -1 days while requested is 365 days
[2024-11-26 09:00:27] [UserUtils.c:2309] [ERROR] SetMaxDaysBetweenPasswordChanges: chage -M 365 cloudtest: failed: chage: failure while writing changes to /etc/shadow

Looking at syslog shows:

Nov 26 09:00:34 vm setroubleshoot[9443]: SELinux is preventing /usr/bin/chage from write access on the file /etc/shadow-. For complete SELinux messages run: sealert -l 0cb08071-377d-4ba7-958d-7f9ed6c5e08e
Nov 26 09:00:34 vm setroubleshoot[9443]: SELinux is preventing /usr/bin/chage from write access on the file /etc/shadow-.

                                         *****  Plugin restorecon (94.8 confidence) suggests   ************************

                                         If you want to fix the label.
                                         /etc/shadow- default label should be shadow_t.
                                         Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accord>
                                         Do
                                         # /sbin/restorecon -v /etc/shadow-

                                         *****  Plugin catchall_labels (5.21 confidence) suggests   *******************

                                         If you want to allow chage to have write access on the shadow- file
                                         Then you need to change the label on /etc/shadow-
                                         Do
                                         # semanage fcontext -a -t FILE_TYPE '/etc/shadow-'
                                         where FILE_TYPE is one of the following: afs_cache_t, faillog_t, krb5_host_rcache_t, lastlog_t, passwd_file_t, puppet_tmp_t, security_t, shadow_t, sssd_public_t, sssd_var_lib_t, user_cron>
                                         Then execute:
                                         restorecon -v '/etc/shadow-'


                                         *****  Plugin catchall (1.44 confidence) suggests   **************************

                                         If you believe that chage should be allowed write access on the shadow- file by default.
                                         Then you should report this as a bug.
                                         You can generate a local policy module to allow this access.
                                         Do
                                         allow this access for now by executing:
                                         # ausearch -c 'chage' --raw | audit2allow -M my-chage
                                         # semodule -X 300 -i my-chage.pp

Restoring the selinux context shows that the file has the wrong context after ASB runs:

[jeremi@vm ~]$ sudo /sbin/restorecon -Fv /etc/shadow-
Relabeled /etc/shadow- from unconfined_u:object_r:etc_t:s0 to system_u:object_r:shadow_t:s0

The selinux context is lost when a temporary file is created to edit the contents of the config file. Restore it after renaming by running restorecon -F.

Checklist

• I have read the contribution guidelines.
• All unit tests are passing.
• I have merged the latest main branch prior to this PR submission.
• I submitted this PR against the main branch.