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.
DescriptionCarl Henrik Lunde
2017-09-11 10:56:43 UTC
Description of problem:
After upgrading to 7.4 we've seen crashes on clients using nouveau drivers. Some machines do not recover after reboot, but hang with "Failed to load SELinux policy, freezing."
It seems like semodule -i / filesystem manipulation when modifying the policy is not crash safe/synced/transactional in any way, which increases the chances of corruption.
Version-Release number of selected component (if applicable):
How reproducible:
Easy
Steps to Reproduce:
tl;dr: make a selinux policy change and hard reset the system
1. sudo yum install policycoreutils-python selinux-policy-devel
2. Create a any policy (anything should do, this is just a sample):
cat > postgreylocal.te
module postgreylocal 1.0;
require {
type postfix_smtpd_t;
type postfix_spool_t;
type initrc_t;
class sock_file write;
class unix_stream_socket connectto;
}
#============= postfix_smtpd_t ==============
allow postfix_smtpd_t initrc_t:unix_stream_socket connectto;
allow postfix_smtpd_t postfix_spool_t:sock_file write;
3. make -f /usr/share/selinux/devel/Makefile
4. sudo semodule -i postgreylocal.pp
# emulate a crash or use of "the swedish button" aka "the big red switch"
5. echo b | sudo tee /proc/sysrq-trigger
Actual results:
Failed to load SELinux policy, freezing.
Expected results:
To avoid unbootable systems, such changes to the policy files should be best effort "transactional". Perhaps even using the previous policy if a crash happens when a new version of the policy is made.
Additional info:
Comment 2Carl Henrik Lunde
2017-09-11 13:20:30 UTC
A workaround is to use sync(1) after semodule, but that still leaves the system vulnerable while the command runs. I think proper use of fsync/fdatasync and perhaps rename would be a good solution.
PS! I've only tested the reproduction steps on XFS.
This issue was not selected to be included in Red Hat Enterprise Linux 7.7 because it is seen either as low or moderate impact to a small number of use-cases. The next release will be in Maintenance Support 1 Phase, which means that qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available.
We will now close this issue, but if you believe that it qualifies for the Maintenance Support 1 Phase, please re-open; otherwise, we recommend moving the request to Red Hat Enterprise Linux 8 if applicable.
Description of problem: After upgrading to 7.4 we've seen crashes on clients using nouveau drivers. Some machines do not recover after reboot, but hang with "Failed to load SELinux policy, freezing." It seems like semodule -i / filesystem manipulation when modifying the policy is not crash safe/synced/transactional in any way, which increases the chances of corruption. Version-Release number of selected component (if applicable): How reproducible: Easy Steps to Reproduce: tl;dr: make a selinux policy change and hard reset the system 1. sudo yum install policycoreutils-python selinux-policy-devel 2. Create a any policy (anything should do, this is just a sample): cat > postgreylocal.te module postgreylocal 1.0; require { type postfix_smtpd_t; type postfix_spool_t; type initrc_t; class sock_file write; class unix_stream_socket connectto; } #============= postfix_smtpd_t ============== allow postfix_smtpd_t initrc_t:unix_stream_socket connectto; allow postfix_smtpd_t postfix_spool_t:sock_file write; 3. make -f /usr/share/selinux/devel/Makefile 4. sudo semodule -i postgreylocal.pp # emulate a crash or use of "the swedish button" aka "the big red switch" 5. echo b | sudo tee /proc/sysrq-trigger Actual results: Failed to load SELinux policy, freezing. Expected results: To avoid unbootable systems, such changes to the policy files should be best effort "transactional". Perhaps even using the previous policy if a crash happens when a new version of the policy is made. Additional info: