GNOME Bugzilla – Bug 681103
Network Manager Clobbers /etc/resolv.conf and default route after plugin of new device (e.g. USB)
Last modified: 2013-05-06 13:24:18 UTC
This bug could be used as a physical DoS attack on a machine running NetworkManager. My configuration: Tested in Debian Wheezy with version 0.9.5.95-1 I actually do not want to use Network Manager at all. These systems are configured with configuration management and do not need dynamic network settings. However, in Debian gnome depends upon installation of NetworkManager (network-manager), so I must install NetworkManager to install gnome. chiestand@sagan:/$ cat /etc/NetworkManager/NetworkManager.conf [main] plugins=ifupdown,keyfile [ifupdown] managed=false In /etc/network/interfaces I only have 2 interfaces configured: lo eth0 So network manager manages any non-defined interfaces, such as eth1 (onboard) or a USB network device. What Happened, Part One: A user reported that when she plugged her cell phone into her computer to charge it, she lost all network access. I verified this. The phone (HTC Hera 110 running Windows Mobile 6) acts as a network device much like a USB ethernet dongle. Upon plug-in, Network Manager runs and replaces /etc/resolv.conf with the blank file "# Generated by NetworkManager" because the phone is not actually configured to act as a gateway and Network Manager decides to use null information. However, I'm not sure exactly what the phone is communicating to the computer. What I Expected Would Happen, Part One: /etc/resolv.conf would remain unchanged What Happened, Part Two: Further testing with a USB ethernet cable that is connected to our network showed that Network Manager changes the default route. Here is the normal route: chiestand@sagan:/tmp$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 eth0 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 Here is the route after plugging in a USB ethernet device: 0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 eth3 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3 Notice the default route has been switch to use eth3 instead of eth0. This is bad because the system hangs after eth3 is unplugged, due to NFS and LDAP failures. What I Expected Would Happen, Part Two: Either: Network Manager would not modify the route -or- Network Manager would restore the route to the original route after the USB ethernet cable was unplugged Recommend Solution(s): First, Network Manager should never replace /etc/resolv.conf with an empty file. If it has no resolver data, it should not erase what is current. Second, if Network Manager truly is required for gnome, but it is not required to be running, there should be a way to disable it. On Debian, there would be a disable variable in /etc/default/network-manager that you could set to avoid running NetworkManager. If NM is required for gnome, and must be running, then there should be a way to disable it from managing ANY network devices. Currently you can only disable NM from managing devices configured in /etc/network/interfaces. If NM is not required for gnome, I will file a Debian bug such that gnome-core should not depend on network-manager-gnome (which depends on network-manager). How to reproduce: 1. Start Network Manager. 2. Plug in an additional ethernet device that has not already been configured (such as USB ethernet dongle). 3. /etc/resolv.conf and route is clobbered Thanks.
This bug has also been reported here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598911
> This bug could be used as a physical DoS attack on a machine running > NetworkManager. There are lots of other ways to physically DoS any machine... > My configuration: > Tested in Debian Wheezy with version 0.9.5.95-1 > > I actually do not want to use Network Manager at all. Nobody should be forced to use NetworkManager. Forcing someone to use it should be considered a bug. > These systems are > configured with configuration management and do not need dynamic network > settings. However, in Debian gnome depends upon installation of NetworkManager > (network-manager), so I must install NetworkManager to install gnome. Even though in my opinion Gnome packages should not depend on NetworkManager, it is not such a big deal. You don't have to use NM. Just disable it with your init system and file/comment bugreports if this doesn't work for you. If NM spuriously restarts for you, please check the init configuration *and* the configuration of dbus (especialy dbus activation). > chiestand@sagan:/$ cat /etc/NetworkManager/NetworkManager.conf > [main] > plugins=ifupdown,keyfile > > [ifupdown] > managed=false I didn't even know we have this one. > In /etc/network/interfaces I only have 2 interfaces configured: > lo > eth0 > > So network manager manages any non-defined interfaces, such as eth1 (onboard) > or a USB network device. Please see bug 673537. > What Happened, Part One: > A user reported that when she plugged her cell phone into her computer to > charge it, she lost all network access. I verified this. The phone (HTC Hera > 110 running Windows Mobile 6) acts as a network device much like a USB ethernet > dongle. Upon plug-in, Network Manager runs and replaces /etc/resolv.conf with > the blank file "# Generated by NetworkManager" because the phone is not > actually configured to act as a gateway and Network Manager decides to use null > information. This should most probably be handled more gracefully. But NM normally assumes that no connection warrants empty resolv.conf. But probably the smooth assumption of connections and smooth restart features of NM are also affected by this behavior. > However, I'm not sure exactly what the phone is communicating to > the computer. It's probably not so important. In this case I belive NM reacts just to the fact of newly managing an interface. > What I Expected Would Happen, Part One: > /etc/resolv.conf would remain unchanged That might be a better behaviour. But it has consequences. > What Happened, Part Two: > Further testing with a USB ethernet cable that is connected to our network > showed that Network Manager changes the default route. Interesting. > Here is the normal route: > chiestand@sagan:/tmp$ route -n > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use Iface > 0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 eth0 > 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 > > Here is the route after plugging in a USB ethernet device: > 0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 eth3 > 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 > 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3 Please use 'ip route' next time for better output. But the 'metric' is there and it's the same for eth0 and eth3. This can break thing, too. > Notice the default route has been switch to use eth3 instead of eth0. This is > bad because the system hangs after eth3 is unplugged, due to NFS and LDAP > failures. These services should be fixed then. System should never hang up just because of network configuration changes. But that's another case. > What I Expected Would Happen, Part Two: > Either: > Network Manager would not modify the route This is a policy decision. But USB ethernet should probably *not* be favoured over internal NIC. > -or- > Network Manager would restore the route to the original route after the USB > ethernet cable was unplugged It can't reasonably do it before as NM can't predict the user's intention to remove the USB ethernet cable. To fix this, kernel cooperation would be needed, so it can be considered a much harder issue. > Recommend Solution(s): > First, Network Manager should never replace /etc/resolv.conf with an empty > file. Sounds reasonable but can have consequences. > If it has no resolver data, it should not erase what is current. I'm afraid we need to remove network configuration in many cases. But this requires further research. > Second, if Network Manager truly is required for gnome, NM should not be requred for running gnome and IMO not even for installing. But others may have different opinions. > but it is not required > to be running, there should be a way to disable it. NM is started by the init system. NM should not be started by any other means except for debugging. The init system should be able to cope with enabling/disabling services. If NM is automatically started by other means, it is a bug and should be reported accordingly. > If NM is required for gnome, and must be running, then there should be a way to > disable it from managing ANY network devices. When NM is running, it should be configurable *not* to auto-manage new devices. It currently supports MAC blacklisting but it should also support whitelisting as described in bug 673537 and administratively started device management as described in bug 680909. > If NM is not required for gnome, I will file a Debian bug such that gnome-core > should not depend on network-manager-gnome (which depends on network-manager). Please do and if it *is* required, please file a Gnome bug to make it at least running optionally. Also, this greatly depends on what version of Gnome are you running. > How to reproduce: > 1. Start Network Manager. > 2. Plug in an additional ethernet device that has not already been configured > (such as USB ethernet dongle). > 3. /etc/resolv.conf and route is clobbered > > Thanks. Thank *you*! You have just described a very simple use case that triggers so many problems and missing features of NetworkManager. This bug report will have to be triaged and divided into separate bug reports for separate problems. I tried to link to all bug reports that have already been filed. Assigning to myself for the purpose of triaging (not for the purpose of fixing all these bugs).
> > This bug could be used as a physical DoS attack on a machine running > > NetworkManager. > > There are lots of other ways to physically DoS any machine… Good point. The main difference here is that it would probably be done unintentionally :-) > > Notice the default route has been switch to use eth3 instead of eth0. This is > > bad because the system hangs after eth3 is unplugged, due to NFS and LDAP > > failures. > > These services should be fixed then. System should never hang up just because > of network configuration changes. But that's another case. Perhaps a bad choice of word, I didn't mean indefinite hang, but rather very long delay (and likely failure). This is largely unavoidable when using nfs-mounted home directories with ldap and a route failure occurs. > > What I Expected Would Happen, Part Two: > > Either: > > Network Manager would not modify the route > > > This is a policy decision. But USB ethernet should probably *not* be favoured > over internal NIC. Strong agreement on the policy decision. Another use case to consider is when a user plugs in and unplugs a second (non-USB) ethernet NIC > > Recommend Solution(s): > > First, Network Manager should never replace /etc/resolv.conf with an empty > > file. > > Sounds reasonable but can have consequences. I can't imagine a consequence worse than an empty resolv.conf. The worst that could happen is that the NS used is not reachable - but the effect of that is exactly the same as an empty resolv.conf. So you might as well leave resolv.conf unempty because it is better than nothing. An alternative is to work out a way to more intelligently set resolv.conf so a guessing game is not required. And even in this scenario, resolv.conf is never empty. > > If it has no resolver data, it should not erase what is current. > > I'm afraid we need to remove network configuration in many cases. But this > requires further research. That seems appropriate. > > Second, if Network Manager truly is required for gnome, > > NM should not be requred for running gnome and IMO not even for installing. But > others may have different opinions. > > but it is not required > > to be running, there should be a way to disable it. > NM is started by the init system. NM should not be started by any other means > except for debugging. The init system should be able to cope with > enabling/disabling services. If NM is automatically started by other means, > it is a bug and should be reported accordingly. Debian does not currently support a way to disable NM in init, e.g. by having a DISABLE shell variable. I requested this in a Debian bug report. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685742 > > If NM is not required for gnome, I will file a Debian bug such that gnome-core > > should not depend on network-manager-gnome (which depends on network-manager). > Please do and if it *is* required, please file a Gnome bug to make it at least > running optionally. Also, this greatly depends on what version of Gnome are you > running. I sent an email to the Debian Gnome package maintainers enquiring on this topic. Thanks a lot for the thorough reply. I appreciate it greatly.
(In reply to comment #3) > > > This bug could be used as a physical DoS attack on a machine running > > > NetworkManager. > > > > There are lots of other ways to physically DoS any machine… > > Good point. The main difference here is that it would probably be > done unintentionally :-) > > > > > > Notice the default route has been switch to use eth3 instead of eth0. This is > > > bad because the system hangs after eth3 is unplugged, due to NFS and LDAP > > > failures. > > > > These services should be fixed then. System should never hang up just because > > of network configuration changes. But that's another case. > > Perhaps a bad choice of word, I didn't mean indefinite hang, but rather very > long delay (and likely failure). This is largely unavoidable when using > nfs-mounted > home directories with ldap and a route failure occurs. > > > > > What I Expected Would Happen, Part Two: > > > Either: > > > Network Manager would not modify the route > > > > > This is a policy decision. But USB ethernet should probably *not* be favoured > > over internal NIC. > > Strong agreement on the policy decision. Another use case to consider is when > a user plugs in and unplugs a second (non-USB) ethernet NIC > > > > > > Recommend Solution(s): > > > First, Network Manager should never replace /etc/resolv.conf with an empty > > > file. > > > > Sounds reasonable but can have consequences. > > I can't imagine a consequence worse than an empty resolv.conf. The worst > that could happen is that the NS used is not reachable - but the effect of > that is exactly the same as an empty resolv.conf. So you might as well > leave resolv.conf unempty because it is better than nothing. Unfortunately not. Empty resolv.conf will lead to immediate errors, while non-empty one can lead to timeouts which is a bad user experience. And this also applies to reverse DNS. This is too defensive and there's no point in keeping old DNS configuration when you don't have a default gateway anyway. > An alternative is to work out a way to more intelligently set resolv.conf so > a guessing game is not required. And even in this scenario, resolv.conf is > never empty. What guessing game it is? > > > If it has no resolver data, it should not erase what is current. > > > > I'm afraid we need to remove network configuration in many cases. But this > > requires further research. > > That seems appropriate. > > > > > > Second, if Network Manager truly is required for gnome, > > > > NM should not be requred for running gnome and IMO not even for installing. But > > others may have different opinions. > > > > but it is not required > > > to be running, there should be a way to disable it. > > > NM is started by the init system. NM should not be started by any other means > > except for debugging. The init system should be able to cope with > > enabling/disabling services. If NM is automatically started by other means, > > it is a bug and should be reported accordingly. > > Debian does not currently support a way to disable NM in init, e.g. by having > a DISABLE shell variable. I requested this in a Debian bug report. > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685742 chkconfig/update-rc.d as suggested in the debian bug won't work? > > > If NM is not required for gnome, I will file a Debian bug such that gnome-core > > > should not depend on network-manager-gnome (which depends on network-manager). > > > Please do and if it *is* required, please file a Gnome bug to make it at least > > running optionally. Also, this greatly depends on what version of Gnome are you > > running. > > > I sent an email to the Debian Gnome package maintainers enquiring on this > topic. > > > Thanks a lot for the thorough reply. I appreciate it greatly. Thanks.
For explicit priority setting, please see: https://bugzilla.gnome.org/show_bug.cgi?id=580018 NetworkManager master now supports turning off automatically generated connections, see bug 688857. We don't want to put obsolete information to /etc/resolv.conf and we will most probably prefer using a local recursive nameserver in the future. If there's anything else I've forgotten, a new bug report should be started to avoid confusion. Thanks.