Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1686660 - firewalld fails to start in current Rawhide after Server default install ("goto 'PRE_FedoraServer' is not a chain")
Summary: firewalld fails to start in current Rawhide after Server default install ("go...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: rawhide
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa
: 1688185 (view as bug list)
Depends On:
Blocks: F31BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2019-03-07 23:56 UTC by Adam Williamson
Modified: 2019-04-05 17:58 UTC (History)
9 users (show)

Fixed In Version: selinux-policy-3.14.4-8.fc31
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-04-05 17:58:47 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Adam Williamson 2019-03-07 23:56:49 UTC 
In Fedora-Rawhide-20190306.n.1, all firewall tests failed. There seem to be two separate bugs in two different tests. In this one, a default install is run from the Server DVD (with the default Server package set). This proceeds successfully. The test boots the installed system and runs 'firewall-cmd --state', expecting it to succeed (success indicates the firewall is running, failure indicates it is not). It fails, with the output 'failed'. Looking at the firewalld service logs, we see this:

Mar 06 17:21:04 localhost.localdomain systemd[1]: Starting firewalld - dynamic firewall daemon...
Mar 06 17:21:06 localhost.localdomain systemd[1]: Started firewalld - dynamic firewall daemon.
Mar 06 17:21:08 localhost.localdomain firewalld[686]: WARNING: ip6tables not usable, disabling IPv6 firewall.
Mar 06 17:21:08 localhost.localdomain firewalld[686]: ERROR: UNKNOWN_ERROR: 'ip6tables' backend does not exist
Mar 06 17:21:08 localhost.localdomain firewalld[686]: ERROR: COMMAND_FAILED: UNKNOWN_ERROR: 'ip6tables' backend does not exist
Mar 06 17:21:08 localhost.localdomain firewalld[686]: ERROR: '/usr/sbin/iptables-restore -w -n' failed: iptables-restore v1.8.0 (legacy): goto 'PRE_FedoraServer' is not a chain
                                                      
                                                      Error occurred at line: 2
                                                      Try `iptables-restore -h' or 'iptables-restore --help' for more information.
Mar 06 17:21:08 localhost.localdomain firewalld[686]: ERROR: COMMAND_FAILED: '/usr/sbin/iptables-restore -w -n' failed: iptables-restore v1.8.0 (legacy): goto 'PRE_FedoraServer' is not a chain
                                                      
                                                      Error occurred at line: 2
                                                      Try `iptables-restore -h' or 'iptables-restore --help' for more information.

Proposing as an F31 Beta blocker per "After system installation without explicit firewall configuration, the system firewall must be active on all non-loopback interfaces." - https://fedoraproject.org/wiki/Basic_Release_Criteria#Firewall_configuration , this test is specifically meant to enforce that criterion. Will move to F30 if this also affects it, once we finally get a compose.
Comment 1 Eric Garver 2019-03-08 20:22:45 UTC 
This is an selinux policy issue. I expect the same is true for bug 1686654.
I think both bugs can be reassigned to selinux-policy.

--->8---

[root@fedora ~]# setenforce 0
[root@fedora ~]# systemctl restart firewalld
[root@fedora ~]# firewall-cmd --state
running

[root@fedora ~]# setenforce 1
[root@fedora ~]# systemctl restart firewalld                                                                                                                                                   
[root@fedora ~]# firewall-cmd --state                                                                                                                                         
failed

[root@fedora ~]# audit2allow -a
#============= iptables_t ==============

#!!!! This avc can be allowed using the boolean 'domain_can_mmap_files'
allow iptables_t kmod_exec_t:file map;
allow iptables_t kmod_exec_t:file { execute execute_no_trans open read };

#!!!! This avc can be allowed using the boolean 'domain_can_mmap_files'
allow iptables_t modules_object_t:file map;
allow iptables_t self:system module_load;
Comment 2 Adam Williamson 2019-03-08 20:44:05 UTC 
Ah, good call, confirmed. 'ausearch -ts recent -m avc' after starting firewalld in permissive mode:

time->Fri Mar  8 15:41:58 2019
type=AVC msg=audit(1552077718.976:265): avc:  denied  { execute } for  pid=1233 comm="ip6tables" name="kmod" dev="dm-0" ino=140171 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:kmod_exec_t:s0 tclass=file permissive=1
----
time->Fri Mar  8 15:41:58 2019
type=AVC msg=audit(1552077718.976:266): avc:  denied  { read open } for  pid=1233 comm="ip6tables" path="/usr/bin/kmod" dev="dm-0" ino=140171 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:kmod_exec_t:s0 tclass=file permissive=1
----
time->Fri Mar  8 15:41:58 2019
type=AVC msg=audit(1552077718.976:267): avc:  denied  { execute_no_trans } for  pid=1233 comm="ip6tables" path="/usr/bin/kmod" dev="dm-0" ino=140171 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:kmod_exec_t:s0 tclass=file permissive=1
----
time->Fri Mar  8 15:41:58 2019
type=AVC msg=audit(1552077718.976:268): avc:  denied  { map } for  pid=1233 comm="modprobe" path="/usr/bin/kmod" dev="dm-0" ino=140171 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:kmod_exec_t:s0 tclass=file permissive=1
----
time->Fri Mar  8 15:41:58 2019
type=AVC msg=audit(1552077718.978:269): avc:  denied  { read } for  pid=1233 comm="modprobe" name="modules.softdep" dev="dm-0" ino=264448 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:modules_dep_t:s0 tclass=file permissive=1
----
time->Fri Mar  8 15:41:58 2019
type=AVC msg=audit(1552077718.979:270): avc:  denied  { open } for  pid=1233 comm="modprobe" path="/usr/lib/modules/5.1.0-0.rc0.git1.1.fc31.x86_64/modules.softdep" dev="dm-0" ino=264448 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:modules_dep_t:s0 tclass=file permissive=1
----
time->Fri Mar  8 15:41:58 2019
type=AVC msg=audit(1552077718.979:271): avc:  denied  { getattr } for  pid=1233 comm="modprobe" path="/usr/lib/modules/5.1.0-0.rc0.git1.1.fc31.x86_64/modules.softdep" dev="dm-0" ino=264448 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:modules_dep_t:s0 tclass=file permissive=1
----
time->Fri Mar  8 15:41:58 2019
type=AVC msg=audit(1552077718.979:272): avc:  denied  { map } for  pid=1233 comm="modprobe" path="/usr/lib/modules/5.1.0-0.rc0.git1.1.fc31.x86_64/modules.dep.bin" dev="dm-0" ino=266153 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:object_r:modules_dep_t:s0 tclass=file permissive=1
----
time->Fri Mar  8 15:41:59 2019
type=AVC msg=audit(1552077719.017:273): avc:  denied  { module_load } for  pid=1233 comm="modprobe" scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:iptables_t:s0 tclass=system permissive=1
Comment 3 Lukas Vrabec 2019-03-11 17:55:07 UTC 
commit f36721500c5e2596fc4157cfab3b88e3b1bda7a8
Author: Lukas Vrabec <lvrabec>
Date:   Mon Mar 11 09:52:56 2019 +0100

    Fix interface modutils_run_kmod() where was used old interface modutils_domtrans_insmod instead of new one modutils_domtrans_kmod()
    Resolves: rhbz#1686660
Comment 4 Eric Garver 2019-03-13 16:29:54 UTC 
*** Bug 1688185 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.