Bug 802415 - ifup/ifdown should inform firewalld about network zones
Summary: ifup/ifdown should inform firewalld about network zones
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: 18
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-12 13:52 UTC by Jiri Popelka
Modified: 2014-03-17 03:30 UTC (History)
9 users (show)

Fixed In Version: initscripts-9.37-1.fc17
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-12-11 05:58:14 UTC
Type: ---


Attachments (Terms of Use)
patch (2.63 KB, patch)
2012-03-12 13:53 UTC, Jiri Popelka
no flags Details | Diff

Description Jiri Popelka 2012-03-12 13:52:04 UTC
Default firewall solution in F17 will most likely [1] be FirewallD [2].
It adds a model called 'network zones' [3] which is basically a trust
level for a network connection.
This 'zone' could be changed (default zone is called 'public' and it's
mostly untrusted) for example in NetworkManager applet (this GUI part is still not done atm I think) and NM stores [4] this information
into /etc/sysconfig/network-scripts/ifcfg-<iface> as ZONE=<zone>.
Every time NM starts an interface it tells firewalld which zone the
interface belongs to and when the connection
gets down the firewalld is also informed about that.
But because there have been people (including me) who have still been using
'network' service instead of NM it would be good if initscripts could
do the same and inform firewalld about zones the interfaces belong to.

I see I just missed the 9.35 release so this probably won't make it into F17, will it ?


[1] https://fedorahosted.org/fesco/ticket/805
[2] https://fedoraproject.org/wiki/Features/DynamicFirewall
[3] https://fedoraproject.org/wiki/FirewallD/#Network_zones:_Network_security_model
[4] http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=3e11682ddc69037a06a9bd70abf2739eb43e9876

Comment 1 Jiri Popelka 2012-03-12 13:53:08 UTC
Created attachment 569403 [details]
patch

Comment 2 Bill Nottingham 2012-03-12 16:01:38 UTC
Why do we need to inform the firewall about devices coming and going - it doesn't listen on netlink?

Comment 3 Thomas Woerner 2012-03-12 16:30:43 UTC
No, firewalld does not listen on netlink.

If NM is in use, it will tell firewalld to add an interface to a zone and to remove it also later on again. NM is providing the information needed by firewalld - also the zone to use, because NM knows about the connection. The plan here is to select a zone by environment (gateway, router, ..) also for wired connections in the future.

If NM is not in use, firewalld does not know about connections and interfaces.

Comment 4 Jiri Popelka 2012-03-13 10:05:14 UTC
Well, it would probably be possible for firewalld to itself monitor when interfaces are getting up and down. But the information to which zone the interface belongs is a property of the connection, stored in /etc/sysconfig/network-scripts/ifcfg-<iface> and firewalld itself doesn't store it anywhere. So for getting this information firewalld would need to obtain the value for ZONE key from ifcfg-<iface>.
And to me it seems cleaner when only NetworkManager and initscripts access these
ifcfg-<iface> files.

Comment 5 Bill Nottingham 2012-03-13 16:20:19 UTC
Agreed on that regard. However, I do want to confirm:

- device eth0 brought up in Zone 1 - firewalld is called to specify this
- device eth0 goes down, firewalld is not called for some reason
- device eth0 brought up in Zone 2 - firewalld is called to specify this

Does the right thing happen in firewalld in this case?

Comment 6 Jiri Popelka 2012-03-13 17:05:09 UTC
Depends on what the 'right thing' means ;-)

firewalld doesn't allow to add interface to another zone if it has been in one already. So after you steps the interface will still be in Zone 1.

However there's also changeZone() [1] method which changes zone of interface to specified zone regardless of what zone it has been previously.
It actually removes interface from whatever zone it has been and adds to specified zone. If the interface has not been part of any zone then it works the same as addInterface() so we could possibly use 
firewall-cmd --zone=${ZONE} --change --interface=${DEVICE} > /dev/null 2>&1
instead of
firewall-cmd --zone=${ZONE} --add --interface=${DEVICE} > /dev/null 2>&1

That should solve the problem.

[1] http://git.fedorahosted.org/git/?p=firewalld.git;a=commitdiff;h=61ff98f546b9c4211d8ec38be3b21df0a668ff80

Comment 7 Bill Nottingham 2012-03-13 21:29:35 UTC
Added as http://git.fedorahosted.org/git/?p=initscripts.git;a=commitdiff;h=bf931d4f660af978eef8652ad275fcb7bab0e749 with the following changes:

1) s/add/change/ as mentioned above
2) the firewall poking is done in ifup-post/ifdown-post, to catch more than just ethernet connection types

Comment 8 Fedora Update System 2012-03-16 14:47:10 UTC
initscripts-9.37-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/FEDORA-2012-3654/initscripts-9.37-1.fc17

Comment 9 Fedora Update System 2012-03-20 06:00:40 UTC
Package initscripts-9.37-1.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing initscripts-9.37-1.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-3654/initscripts-9.37-1.fc17
then log in and leave karma (feedback).

Comment 10 Fedora Update System 2012-03-23 17:44:30 UTC
initscripts-9.37-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 11 Jiri Popelka 2012-03-28 10:00:57 UTC
(In reply to comment #7)
> 2) the firewall poking is done in ifup-post/ifdown-post, to catch more than
> just ethernet connection types

The 'firewall poking' had in my original patch been done in ifup-eth before calling of dhcpv6 client, because dhcpv6 client needs open port to get answers from server.

But now the dhcpv6 client doesn't get any answer from server because the correct port is not open at the time when dhcpv6 client starts. The port is opened once the interface is added to a zone, i.e. in ifup-post.

I have one very nice solution, the "-nw" (nowait) option pro dhclient.
From dhclient(8):
-nw    Become a daemon immediately (nowait) rather than waiting until an an IP address has been acquired.

So if we change ifup-eth like this:
- /sbin/dhclient -6 -1 ${DHCPV6C_OPTIONS} ...
+ /sbin/dhclient -6 -1 -nw ${DHCPV6C_OPTIONS} ...

the 'dhclient -6' will be started in background,
ifup-post then adds the interface to a zone, which makes the hole for dhcpv6-client in firewall and
the 'dhclient -6' (still running in background) will finally get answer and configure the interface with IPv6 address. happy end :-)

Moreover this solves the problem I've seen earlier when ifup was blocking initialization for a minute when there's DHCPV6C=yes in ifcfg-<iface> but no running dhcpv6 server.

What do you think ?

Comment 12 Bill Nottingham 2012-03-28 16:44:45 UTC
(In reply to comment #11)
> What do you think ?

Firewall poking should not be required for DHCP to work, period. IPv6 shouldn't be different from IPv4 in this regard.

Comment 13 Jiri Popelka 2012-03-28 17:11:54 UTC
DHCP for IPv4 doesn't need firewall poking because it uses raw sockets thus sidestepping firewall completely.

Comment 14 Jiri Popelka 2012-11-15 14:32:09 UTC
Bill,
could you think about this (in my opinion) harmless change once more ?

ifup-eth:
- /sbin/dhclient -6 -1 ${DHCPV6C_OPTIONS} ...
+ /sbin/dhclient -6 -1 -nw ${DHCPV6C_OPTIONS} ...


(In reply to comment #12)
> Firewall poking should not be required for DHCP to work, period.

The fact that DHCPv4 does not need firewall poking is not a design decision but side-effect of using raw sockets.
From [1]: 
... dhcp uses raw sockets to be able to transmit to and receive packets sent to the all-ones limited broadcast address (255.255.255.255), and being able to send a unicast without an ARP ...
... dhcpd's raw sockets receive packets before the point at which most OS packet filters and firewalls operate ...

> IPv6 shouldn't be different from IPv4 in this regard.

DHCPv6 is completely different protocol which does not need to use these hacks (raw sockets), it can use classic BSD/UDP sockets (also thanks to ipv6 link-local addresses autoconfiguration) and therefore every common firewall blocks DHCPv6 messages unless explicitly allowed.

[1] https://deepthought.isc.org/article/AA-00378/0/Why-does-DHCP-use-raw-sockets.html

Comment 15 Bill Nottingham 2012-11-15 19:08:30 UTC
While backgrounding the daemon will allow it to work via this mechanism, it breaks the synchronous paradigm of ifup, where it doesn't exit unless the interface is configured. Arguably the dhclient -6 code should be checking for an error as well.

Comment 16 Bill Nottingham 2012-12-07 20:58:43 UTC
Modified to just poke it twice (before ifup-ipv6 and the catch-all in ifup-post); should be harmless.

Comment 17 Fedora Update System 2012-12-07 21:37:35 UTC
initscripts-9.42.1-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/initscripts-9.42.1-1.fc18

Comment 18 Fedora Update System 2012-12-08 22:14:02 UTC
Package initscripts-9.42.1-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing initscripts-9.42.1-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-19994/initscripts-9.42.1-1.fc18
then log in and leave karma (feedback).

Comment 19 Fedora Update System 2012-12-11 05:58:16 UTC
initscripts-9.42.1-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.