Project

General

Profile

Bug #11630

Check what to do wrt. NetworkManager's internal DHCP client vs. isc-dhcp-client

Added by intrigeri over 3 years ago. Updated about 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
08/11/2016
Due date:
% Done:

100%

Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:

Description

network-manager (1.2.4-2) unstable; urgency=medium

  * Demote isc-dhcp-client from Depends to Recommends.
    NetworkManager will automatically fall back to the internal dhcp client if
    dhclient is not available. (Closes: #826680)

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826680 for details.

It seems to me that if the internal dhcp client has the features we want (e.g. wrt. not sending the hostname on the network), then we should go for it: isc-dhcp-client is lots of old code, and has a history of security issues.

At the very least, we should make sure that whatever happens, without us changing our Git tree, works and is safe.


Related issues

Related to Tails - Bug #11720: DHCP requests leak hostname on Stretch Resolved 08/25/2016
Related to Tails - Bug #16948: Deal with NetworkManager 1.20+ defaulting to its internal DHCP client Confirmed

Associated revisions

Revision 9c0a3916 (diff)
Added by intrigeri about 3 years ago

Don't install isc-dhcp-client: NetworkManager now includes its own internal DHCP client.

Without this change, on current feature/stretch NetworkManager using
isc-dhcp-client leaks the hostname on the network. The internal DHCP
client can't do much worse. So let's go for it: isc-dhcp-client is lots
of old code, and has a history of security issues.

refs: #11630

Revision 9d604626 (diff)
Added by intrigeri about 3 years ago

Set dhcp-send-hostname=false for the default wired connection as well.

This fixes the hostname leak via DHCP requests for the default wired
connection (regression brought by feature/stretch): apparently, already
existing NM connections do not honor a dhcp-send-hostname setting
defined in /etc/NetworkManager/conf.d/*.conf.

refs: #11630

History

#1 Updated by intrigeri about 3 years ago

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10

According to our test suite, current feature/stretch (with isc-dhcp-client) does leak the hostname on the network: dhcp-send-hostname=false seems to be ignored. The internal DHCP client can't do much worse => I'll give it a try.

#2 Updated by intrigeri about 3 years ago

Just switching to the internal DHCP client does not fix the hostname leak. I'll try other things such as:

  • set dhcp-send-hostname=false in config/chroot_local-includes/etc/NetworkManager/system-connections/Wired connection (in case the fact that it exists already makes it ignore the defaults we set in config/chroot_local-includes/etc/NetworkManager/conf.d/dhcp-hostname.conf
  • drop customization of the list of plugins
  • set dhcp-send-hostname=false directly in NetworkManager.conf
  • set dhcp-send-hostname=false in a [ip] block
  • set dhcp-send-hostname=false in a [ip4] block

#3 Updated by intrigeri about 3 years ago

Once this is fixed, somehow: wake sure that we forbid setting the hostname to a value controlled by the DHCP server.

#4 Updated by intrigeri about 3 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 10 to 100

Fixing the DHCP hostname leak seems to be orthogonal to this issue, so I'm going to move this topic to the backburner for a while: as long as Debian does not changes the default we'll stick to isc-dhclient. It certainly has a not-so-good security history, but at least it's a separate process (that we confine with AppArmor), and it has been attacked for a while, contrary to the brand new code in NM => it's not obvious which one is safest, so the status quo wins for now since it's less work and risk of breakage for us.

#5 Updated by intrigeri about 3 years ago

  • Related to Bug #11720: DHCP requests leak hostname on Stretch added

#6 Updated by intrigeri 3 months ago

  • Related to Bug #16948: Deal with NetworkManager 1.20+ defaulting to its internal DHCP client added

Also available in: Atom PDF