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.
Description of problem: This isn't exactly a bug but a usage consideration. The remediation script correctly implements this fix but if the systems network interface has not been explicitly assigned to a zone then after firewalld gets restarted you will loose all network communication with the system.
I suggest that either a warning be implemented or that the remediation script first checks that at least one network interface has been explicitly assigned to a zone, perhaps the "public"zone as that would avoid loss of network communication with the system.
Version-Release number of selected component (if applicable): openscap-1.2.9-5, SSG 0.1.29.1, USGCB/STIG Profile
How reproducible: Reproducible under the below circumstances
Steps to Reproduce:
1. Make sure that your NIC does not have the zone explicitly set in the config
2. Run openscap with the remediation function
3. Restart the firewalld service or reboot the system
Actual results: Loss of all network communication
Expected results: Warning or settings change to prevent this situation
Additional info: As stated above, this is not really a bug as much as a disruptive situation. Additional information should be supplied in the documentation of this security enhancement that warns of the need to have explicitly set your NICs to a zone, probably "public" to avoid loss of network communication. If possible a part of the remediation scripts function should be to check to ensure this has been done prior to changing the default zone.
Comment 2Watson Yuuma Sato
2017-11-16 13:00:18 UTC
Hello, thank you for suggestion.
We have tried to tackled the problem by adding remediation to Rule that opens a door for SSH, but this path showed it self to be troublesome, see https://github.com/OpenSCAP/scap-security-guide/pull/2285.
We ended up dropping remediation for this Set Default firewalld Zone: https://github.com/OpenSCAP/scap-security-guide/pull/2328
The remediation suggestion is interesting and may enable remediation for "Set Default firewalld Zone" to come back.
Unfortunately this will have to be postponed.
We have removed remediation of this script in Bug 1478414, so it is no longer breaking systems.
For making the automated remediation more clever, we have decided to not go that way. We would have to base it on some simplifying assumption anyway, and networking in the enterprise environments can be quite complex. So any assumption we would take would break it for someone, somehow.
Closing as wontfix.