Bug 982740
Summary: | IPV6INIT=no does not disable IPv6 | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Christian Schmitt <c.schmitt> | ||||
Component: | NetworkManager | Assignee: | Dan Williams <dcbw> | ||||
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 19 | CC: | aaron, ackistler, bughunt, cra, cristian.ciupitu, c.schmitt, dave, dcbw, ellenshull, fche, fedoraproservices, fernando, h.reindl, initscripts-maint-list, joshua, kvolny, lukas+fedora, matt.castelein, nicolas.vieville, psimerda, rtc, rvokal, shyam_iyer, swadeley, troels, wwlinuxengineering, zing | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | 496444 | Environment: | |||||
Last Closed: | 2015-02-17 16:01:31 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Christian Schmitt
2013-07-09 17:46:38 UTC
The other bug was moved to F19. Duplicates? I'm sorry, maybe I shouldn't have moved this to F19. I apologize if this was the wrong thing to do. (In reply to joshua from comment #2) > I'm sorry, maybe I shouldn't have moved this to F19. I apologize if this > was the wrong thing to do. No problem, I think that was the right thing to do. Now just let the packagers (most probably Dan Williams) do what they see fit with the existing bug reports. For the record, we're talking about bug 496444. Btw i cloned the bug since he will still appears on fedora 19. Maybeits a very trivial bug. But still a odd behavior. I mean i have a ignore button or a ipv6 on/off button in nm that correctly sets ipv6init to no but nothing happens then. The value will just getting ignored. I would give any infos you need if somebody want to fix it. Christian, the “Fedora End Of Life” message in the other bug report provides the instructions and suggests reopening and changing the version, not cloning. Now the best thing you can do is to keep the bug reports as they are. I couldn't do that somehow, that's why i cloned it. The only thing that i could've edited would be the CC list.. Also some additional infos: I tested this on 2 versions. IPV6INIT gets set by NM but will get ignored. IPV6 is always on per device. (In reply to Christian Schmitt from comment #6) > Also some additional infos: > I tested this on 2 versions. IPV6INIT gets set by NM but will get ignored. > IPV6 is always on per device. Sounds like a problem in the ifcfg reader. +1 for fixing this bug. Please also consider making IPv6INIT the default for all network interfaces, because of IPv6 defaults vulnerability like router advertisements. See: https://lists.fedoraproject.org/pipermail/users/2013-July/437679.html https://lists.fedoraproject.org/pipermail/users/2013-July/437696.html https://lists.fedoraproject.org/pipermail/users/2013-July/437689.html https://lists.fedoraproject.org/pipermail/users/2013-July/437684.html for my aguments in favor of that. I meant; making IPV6INIT=no the default. (In reply to Fernando Lozano from comment #9) > I meant; making IPV6INIT=no the default. Nah that won't be a good default, since it's a system for endusers mostly home users. So IPV6INIT=yes is okai. Just fix the bug to turn it off. Btw. People could use Puppet to turn it off in enviroments that needs IPV6INIT=no on some interfaces. Christian, I don't know there, but here (Brazil) almost all home users, even those with brand new machines and brand new cable / adsl modems, have IPv4 only. Besides IPv6 enabled with protocol defauts by the spec has a lot of security issues and there's a lot of discussion in the IETF about how to solve them, let alone those being implemented by products. So a user with IPv6 enabled from default after installation is vulnerable. The same way we don't recomend running with a firewall turned off, we shouldn't recomend running with IPv6 enabled by default. System defaults after installing should be the ones for most users. IMHO most users still are on IPv4 only networks and won't know what steps to configure a secure IPv6 network if they have it on their LAN or ISP link. So the default should be disabled, and Anaconda / Network Manager provide an easy way to enable for those who know how to setup IPv6 or are willing to risk it without knowing so well. This is not a Fedora-only problem. Most OSes today come with IPv6 enabled by defailt, and configured in an insecure way (because IPv6 defaults per current IETF standards are insecure). fact is that on a F19 machine with 3.10.0-1.fc20.x86_64 it is impossible to disable ipv6 * not with the old modprobe-tricks * not with for a short time working sysctl settings * not in ifcfg-files * not with kernel-params * and not with /etc/sysconfig/network this is ridiculous - 5 sometimes working options are came and gone every few months the way how to get rid of link-local addresses changes until now on my F17/f18 machines "ipv6disable=1" as kernel param works which was needed after F18 because the in the meantime removed sysctl-settings had no longer any effect there is *no reason* that the machine below has a ipv6 local-link address since ipv6 is disabled on 3 different places and the interface is *statically* configured this is a Üsecurity* problem because having this link-local address inside a network where ipv6 is not used, not supported on the gateway and so servers inside the LAN may have no firewall settings for ipv6 any random machine also coming up with a ipv6-link-local may bypass the existing security concept ____________________________ kernel param "ipv6disable=1" is present [root@rawhide ~]# uname -r 3.10.0-1.fc20.x86_64 [root@rawhide ~]# cat /etc/sysconfig/network NETWORKING=yes NETWORKING_IPV6=no NOZEROCONF=yes [root@rawhide ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 HWADDR=00:0c:29:30:82:b9 ONBOOT=yes BOOTPROTO=static TYPE=Ethernet MODE=Managed IPADDR=192.168.196.18 NM_CONTROLLED=no IPV6INIT=no NETMASK=255.255.255.0 GATEWAY=192.168.196.2 USERCTL=no MTU=1500 [root@rawhide ~]# ifconfig eth0 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.196.18 netmask 255.255.255.0 broadcast 192.168.196.255 inet6 fe80::20c:29ff:fe30:82b9 prefixlen 64 scopeid 0x20<link> ether 00:0c:29:30:82:b9 txqueuelen 1000 (Ethernet) RX packets 690 bytes 59854 (58.4 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 553 bytes 146864 (143.4 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 (In reply to Harald Reindl from comment #12) > fact is that on a F19 machine with 3.10.0-1.fc20.x86_64 it is > impossible to disable ipv6 > Not true, try this sysctl -w net.ipv6.conf.all.disable_ipv6=1 can be set permanently, see man sysctl.conf i am really tired about this topic
i had "net.ipv6.conf.all.disable_ipv6" a long time and it
did *not* disable ipv6 entirely and after someone
suggested "ipv6.disable=1" as kernel param it was solved
which doe snot work now as you can see above
i am tired of all this *permanently* changig ways to disable it - period
if a interface has IPV6INIT=no and/or is *statically* configured with no ipv6 configuration it has not to become a ipv6-lik-local address - period
-------- Original-Nachricht --------
Betreff: [systemd-devel] "sysctl.conf" applied too late
Datum: Wed, 08 Feb 2012 16:07:11 +0100
Von: Reindl Harald <h.reindl>
Organisation: the lounge interactive design
An: Mailing-List systemd <systemd-devel.org>
hi
can someone please take a look at this
in myopinion it is not optimal starting services which
possibly read settings controlled by "systcl.conf"
and after that the local settings get applied
sample below:
after boot smbd is listening on ipv6, sysctl disables this,
but seems to do it after smbd has started, manual restarting
the service stops smbd to listen on ipv6
this may also problematic for all sort of software
-------- Original-Nachricht --------
Betreff: Re: kernel 3.2 / 2.6.42 disable ipv6
Datum: Wed, 08 Feb 2012 15:57:28 +0100
Von: Reindl Harald <h.reindl>
Antwort an: Community support for Fedora users <users.org>
An: users.org
Am 08.02.2012 10:33, schrieb Reindl Harald:
>> sysctl -w net.ipv6.conf.all.disable_ipv6=1
>> echo "net.ipv6.conf.all.disable_ipv6=1" >> /etc/sysctl.conf
>>
>> The first command disables it immediately, the second after a reboot.
>
> thanks, this works!
> "systcl -p" makes changes in /etc/sysctl.conf active immediately
>
> well, my /etc/sysctl.conf is growing and growing :-)
hm - but it seems not to work perfectly
"sysctl.conf" is applyied not at the first begin of the boot-process
so it seems samba as example is starting while the option is not
set, restart it after boot hash fnished removes the ipv6-listening
[root@rh:~]$ netstat -l | grep smb
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 1123/smbd
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 1123/smbd
tcp 0 0 :::445 :::* LISTEN 1123/smbd
tcp 0 0 :::139 :::* LISTEN 1123/smbd
[root@rh:~]$ service smb restart
Redirecting to /bin/systemctl restart smb.service
[root@rh:~]$ netstat -l | grep smb
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 5430/smbd
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 5430/smbd
(In reply to Fernando Lozano from comment #11) > Besides IPv6 enabled with protocol defauts by the spec has a lot of security > issues and there's a lot of discussion in the IETF about how to solve them, > let alone those being implemented by products. So a user with IPv6 enabled > from default after installation is vulnerable. > IPv6 is enabled, at the stack level and the application level, however it is by default not granted access through the firewall, so the default setup does not leave any vulnerabilities. A system can only become vulnerable if the user actively makes changes to the firewall settings to permit the activity. > IPv6 is enabled, at the stack level and the application level and that is *wrong* if ih vae no working way to disable it on the stack level it makes only problems in pure ipv4 networks because applications may believe ipv6 is available which is not the case - period best practices in systems-administration are and where always: disable *anything* ypu do not actively use and so https://bugzilla.redhat.com/show_bug.cgi?id=982740#c12 must not happen > however it is by default not granted access through the firewall
> A system can only become vulnerable if the user actively makes
> changes to the firewall settings to permit the activity
mhh and that is why "Chain INPUT (policy ACCEPT 0 packets, 0 bytes)" of ip6tables after install the service and enable it on the machine where i can not get rid of the link-local address?
[root@rawhide ~]#
Installed: iptables-services.x86_64
[root@rawhide ~]# systemctl enable ip6tables.service
ln -s '/usr/lib/systemd/system/ip6tables.service' '/etc/systemd/system/basic.target.wants/ip6tables.service'
[root@rawhide ~]# systemctl start ip6tables.service
[root@rawhide ~]# ip6tables --list --numeric --verbose
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Oh guys, I don't wanted to discuss what's better to make it default or not. Just the way that it won't should be fixed. When IPV6INIT=no works, we still can discuss what's better, to make it default or not. Currently I think some system administrators want to disable it on 'some' interfaces, since lot's of company networks won't have a ipv6 nameserver and/or gateway, so a link local ipv6 network just brings another layer of problems. but that could be turned off easily with ipv6init=no. I mean when we won't fix this bug, we should greyout or disable the ON/OFF or ignore feature in NetworkManager, since it's useless. (In reply to Harald Reindl from comment #14) > i had "net.ipv6.conf.all.disable_ipv6" a long time and it > did *not* disable ipv6 entirely and after someone Does it still not work? *currently* it seems to work again how can i trust that tomorrow it is not ignored again after all that iterations and how to disable it on a machine with multiple interfaces for specific ones? eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.196.18 netmask 255.255.255.0 broadcast 192.168.196.255 ether 00:0c:29:30:82:b9 txqueuelen 1000 (Ethernet) RX packets 263 bytes 22219 (21.6 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 170 bytes 17793 (17.3 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 (In reply to Harald Reindl from comment #20) > *currently* it seems to work again > > how can i trust that tomorrow it is not ignored again after all that > iterations and how to disable it on a machine with multiple interfaces for > specific ones? The sysctl setting is the correct one documented in the kernel-doc package and it works for several distros. Therefor it is most likely to work. IMHO the other methoeds were mostly workarounds. To disable it for a specifc interface substitute "all" in the sysctl setting with the interface's name. See /usr/share/doc/kernel-doc-*/Documentation/networking/ip-sysctl.txt from the kernel-doc package. and *why* this with the sysctl-settings below? udp6 0 0 :::123 :::* 461/ntpd exactly *this* was the reason for my message to systemd list quoted above and ended with "ipv6disable=1" as kernel-param until now net.ipv6.conf.all.disable_ipv6=1 net.ipv6.conf.all.send_redirects=0 net.ipv6.conf.all.accept_redirects=0 net.ipv6.conf.all.accept_source_route=0 net.ipv6.conf.default.accept_redirects=0 net.ipv6.conf.default.accept_source_route=0 this is all a fragile crap - period It seems to be an ignored setting in Fedora 20. I have to confess I haven't looked into this at any depth (stacking up on IPv6 has been on my todo list since before the War On Terror), but here are the observations: Static configuration of ethernet interface (no NetworkManager, dnsmasq, dhclient or anything) In /etc/sysconfig/network-scripts/ifcfg-em1 After all the IPv4 stuff ---------- # IPV6; to be done IPV6INIT="no" # IPV6_AUTOCONF="yes" # IPV6_DEFROUTE="yes" # IPV6_PEERDNS="yes" # IPV6_PEERROUTES="yes" # IPV6_FAILURE_FATAL="no" ---------- In /etc/sysconfig/network, there is nothing Result: the Ethernet interface gets an IPv6 address (with the ISP "/56" prefix given by the router), although the "lo" does not: -------------------- em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::XXXX:XXff:feXX:XXXX prefixlen 64 scopeid 0x20<link> inet6 2001:7e8:c0bc:1a01:XXXX:XXff:feXX:XXXX prefixlen 64 scopeid 0x0<global> ether XX:XX:XX:XX:XX:XX txqueuelen 1000 (Ethernet) RX packets 36665 bytes 44110657 (42.0 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 24525 bytes 3032172 (2.8 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 em1:DNS: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.2 netmask 255.255.255.0 broadcast 192.168.1.255 ether XX:XX:XX:XX:XX:XX txqueuelen 1000 (Ethernet) -------------------- *** Bug 1009776 has been marked as a duplicate of this bug. *** This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. This bug is still present as of fedora 25! Please reopen the bug. Chosing "Ignore" as the method under "IPv6 Settings" for some NetworkManager connection produces a /etc/sysconfig/network-scripts/ifcfg-$IF with MODE=Managed and IPV6INIT=no but apparently has no effect at all. How hard can it be to fix this bug? You can certainly fix this if you're using the old network-scripts. e.g. service network start (as opposed to systemctl start NetworkManager) just edit the file /etc/sysconfig/network-scripts/ifup-ipv6 Look for a section like this # Test whether IPv6 configuration is disabled for this interface [[ "$IPV6INIT" = [nN0]* ]] && exit 0 and replace that second line with these four lines... if [[ "$IPV6INIT" = [nN0]* ]] ; then echo 1 > /proc/sys/net/ipv6/conf/$DEVICE/disable_ipv6 exit 0 fi As for a fix for NetworkManager itself, after have a short look at the code and a bit of googling, I suspect this fault is actually with NetworkManager itself and not the redhat plugin. SLAAC configuration is done by the kernel and I suspect that NetworkManager is not disabling this behaviour. I was able to find HOWTO's for ArchLinux and Ubuntu which suggest using sysctl.conf to disable the kernels AUTOCONF. I see sections of code in NM which uses sysctl to disable the "accept_ra" when doing shutdown cleanups, but not for startup. I only had a brief look, so I could be wrong. I'd suggest taking this up with the upstream package maintainers. https://wiki.gnome.org/action/show/Projects/NetworkManager There is a good write up here too. http://ask.xmodulo.com/disable-ipv6-linux.html "just edit the file /etc/sysconfig/network-scripts/ifup-ipv6" is by all respect a nonsense recommendation [harry@srv-rhsoft:~]$ rpm -q --file /etc/sysconfig/network-scripts/ifup-ipv6 initscripts-9.69-1.fc25.x86_64 guess what happens when the initscripts package becomes an update... Created attachment 1302571 [details]
/etc/NetworkManager/dispatcher.d/01-ipv6init
Solution for NetworkManager
Save the attached file as /etc/NetworkManager/dispatcher.d/01-ipv6init
make it executable e.g.
# chmod +x /etc/NetworkManager/dispatcher.d/01-ipv6init
# restorecon /etc/NetworkManager/dispatcher.d/01-ipv6init
It looks for NETWORKING_IPV6=no in /etc/sysconfig/network
Also looks in /etc/sysconfig/networking-scripts/ifcfg-DEVICE for IPV6INIT=no
and takes action to disable ipv6 on that DEVICE or globally if set.
This may also be relevant https://bugzilla.redhat.com/show_bug.cgi?id=1402555 Another relevant bug (or feature request) with gnome https://bugzilla.gnome.org/show_bug.cgi?id=682932 It appears that this bug is more to do with NetworkManager itself not having the feature to disable IPv6, it only has method=ignore (which means don't enable and don't disable). |