[Touch-packages] [Bug 1901373] Re: isc-dhcp-server AppArmor Denied on /proc/sys/net/ipv4/ip_local_port_range
Admitting I know very little about apparmor, here is the profile that worked for me: # cat /etc/apparmor.d/usr.sbin.dhcpd # vim:syntax=apparmor #include /usr/sbin/dhcpd { #include #include capability chown, capability dac_override, capability net_bind_service, capability net_raw, capability setgid, capability setuid, capability sys_chroot, network inet raw, network packet raw, /etc/dhcp/dhcpd.conf r, /etc/dhcp/dhcpd6.conf r, /etc/bind/* r, /etc/hosts.allow r, /etc/hosts.deny r, @{PROC}/net/dev r, /usr/sbin/dhcpd rmix, /var/lib/dhcp/dhcpd.leases* rwl, /var/lib/dhcp/dhcpd6.leases* rwl, /{,var/}run/dhcp-server/dhcpd.pid wl, } -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1901373 Title: isc-dhcp-server AppArmor Denied on /proc/sys/net/ipv4/ip_local_port_range Status in isc-dhcp package in Ubuntu: Confirmed Bug description: The following AppArmor denial errors are shown on startup: Oct 25 00:52:00 xxx kernel: [ 556.231990] audit: type=1400 audit(1603601520.710:32): apparmor="DENIED" operation="open" profile="/usr/sbin/dhcpd" name="/proc/sys/net/ipv4/ip_local_port_range" pid=1982 comm="dhcpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Oct 25 00:52:00 xxx kernel: [ 556.232257] audit: type=1400 audit(1603601520.710:33): apparmor="DENIED" operation="open" profile="/usr/sbin/dhcpd" name="/proc/sys/net/ipv4/ip_local_port_range" pid=1982 comm="dhcpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Fix is to edit /etc/apparmor.d/local/usr.sbin.dhcpd to have: @{PROC}/sys/net/ipv4/ip_local_port_range r, 'lsb_release -rd': Description:Ubuntu 20.04.1 LTS Release:20.04 isc-dhcp-server: Installed: 4.4.1-2.1ubuntu5 Candidate: 4.4.1-2.1ubuntu5 Version table: *** 4.4.1-2.1ubuntu5 500 500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status apparmor: Installed: 2.13.3-7ubuntu5.1 Candidate: 2.13.3-7ubuntu5.1 Version table: *** 2.13.3-7ubuntu5.1 500 500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 2.13.3-7ubuntu5 500 500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1901373/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1901373] Re: isc-dhcp-server AppArmor Denied on /proc/sys/net/ipv4/ip_local_port_range
Proposed fix does not work for me, gives AppArmor parser error at line 3: Found unexpected character ''' I am also puzzled that this apparmor profile is completely different in form than others proposed e.g. at: https://github.com/Harvie/AppArmor-Profiles/blob/master/usr.sbin.dhcpd ??? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1901373 Title: isc-dhcp-server AppArmor Denied on /proc/sys/net/ipv4/ip_local_port_range Status in isc-dhcp package in Ubuntu: Confirmed Bug description: The following AppArmor denial errors are shown on startup: Oct 25 00:52:00 xxx kernel: [ 556.231990] audit: type=1400 audit(1603601520.710:32): apparmor="DENIED" operation="open" profile="/usr/sbin/dhcpd" name="/proc/sys/net/ipv4/ip_local_port_range" pid=1982 comm="dhcpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Oct 25 00:52:00 xxx kernel: [ 556.232257] audit: type=1400 audit(1603601520.710:33): apparmor="DENIED" operation="open" profile="/usr/sbin/dhcpd" name="/proc/sys/net/ipv4/ip_local_port_range" pid=1982 comm="dhcpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Fix is to edit /etc/apparmor.d/local/usr.sbin.dhcpd to have: @{PROC}/sys/net/ipv4/ip_local_port_range r, 'lsb_release -rd': Description:Ubuntu 20.04.1 LTS Release:20.04 isc-dhcp-server: Installed: 4.4.1-2.1ubuntu5 Candidate: 4.4.1-2.1ubuntu5 Version table: *** 4.4.1-2.1ubuntu5 500 500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status apparmor: Installed: 2.13.3-7ubuntu5.1 Candidate: 2.13.3-7ubuntu5.1 Version table: *** 2.13.3-7ubuntu5.1 500 500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 2.13.3-7ubuntu5 500 500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1901373/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1611945] Re: /dev/disk/by-path not properly populated for (e)SATA port multiplier disks
Ladies and Gentlemen, The technical stuff is way over my head but I am getting the same syslog errors and the same inconsistent device paths on an HP Proliant ML110 G7 with Ubuntu 16.04.3 kernel 4.4.0-98-generic. It seems clear that no-one is taking ownership of this to fix it in an actual update that ordinary people like me can install in the normal course of system updates. The nature of open source software I guess. However could someone please let me know: - is this just an annoying message that won't be fixed, or are there operational implications? - if there are implications, are they serious? - if they are serious, could you explain (or point me at a resource that explains) in detail, how to install the patch provided. I've never done that before. Thank you in advance! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1611945 Title: /dev/disk/by-path not properly populated for (e)SATA port multiplier disks Status in systemd package in Ubuntu: Confirmed Bug description: We have a just-installed Ubuntu 16.04 LTS machine with a number of disks behind port-multiplier eSATA ports, all of them driven by a SiI 3124 controller (sata_sil24 kernel driver). Our machine sees all disks on all channels, however under 16.04 only one disk from each channel shows up in /dev/disk/by-path/ (all disks show up in /dev/disk/by-id and /dev/disk/by-uuid). For our usage this is a severe defect because we rotate disks in and out of the external enclosure and rely on mounting specific slots in the external enclosure through /dev/disk /by-path. This did not happen in Ubuntu 12.04 LTS, the release that this machine was previously running. According to 'udevadm info --export-db' and 'udevadm test-builtin path_id' and so on, systemd's udev stuff is assigning all drives behind the same port the same disk/by-path data (ID_PATH et al). In 'udevadm info /sys/block/sdX', the 'P:' and 'E: DEVPATH=' values show a difference in the target portion of PCI path, eg: P: /devices/pci:00/:00:01.0/:01:00.0/:02:00.0/ata1/host0/target0:0:0/0:0:0:0/block/sda P: /devices/pci:00/:00:01.0/:01:00.0/:02:00.0/ata1/host0/target0:1:0/0:1:0:0/block/sdb However the 'S: disk/by-path', 'E: DEVLINKS=', and 'E: ID_PATH' portions do not. For both devices above, we see: S: disk/by-path/pci-:02:00.0-ata-1 E: ID_PATH=pci-:02:00.0-ata-1 Naturally only one device can have a /dev/disk/by- path/pci-:02:00.0-ata-1 symlink, so instead of four disks per channel in /dev/disk/by-path we see one. Ubuntu release: 16.04 Package versions from 'apt-cache policy udev systemd': udev: Installed: 229-4ubuntu7 systemd: Installed: 229-4ubuntu7 'journalctl -b' reports that during boot systemd does report some 'appeared twice with different sysfs paths' notes, eg: Aug 10 13:34:21 verdandi systemd[1]: dev-disk-by\x2dpath- pci\x2d:02:00.0\x2data\x2d1\x2dpart1.device: Dev dev-disk-by \x2dpath-pci\x2d:02:00.0\x2data\x2d1\x2dpart1.device appeared twice with different sysfs paths /sys/devices/pci:00/:00:01.0/:01:00.0/:02:00.0/ata1/host0/target0:3:0/0:3:0:0/block/sdd/sdd1 and /sys/devices/pci:00/:00:01.0/:01:00.0/:02:00.0/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1 However it doesn't seem to be reporting this for all port-multiplier drives and their partitions. If it would be useful I can attach full 'udevadm info --export-db' output or the like. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1611945/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1176046] Re: isc-dhcp dhclient listens on extra random ports
Eric, please see 1670303 - pending a substantive solution there, would you be willing to fix dhcpd in the corresponding way that you have fixed dhclient here, i.e. by making separate packages available with or without ddns support? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1176046 Title: isc-dhcp dhclient listens on extra random ports Status in isc-dhcp package in Ubuntu: Fix Released Status in isc-dhcp source package in Trusty: In Progress Status in isc-dhcp source package in Xenial: Fix Released Status in isc-dhcp source package in Yakkety: Fix Released Bug description: [Impact] In trusty, there is only 1 version of dhclient, including #define NSUPDATE, which introduce DDNS functionnality. The DDNS functionnality, generate 2 random extra ports between 1024-65535. Impact reported by users : "One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown." "We have software that was using one of the lower udp ports but it happened to collide with dhclient which seems to allocate 2 random ports." There is a randomization mechanism in libdns that prevent dhclient to take the sysctl values into account (net.ipv4.ip_local_port_range & net.ipv4.ip_local_reserved_ports) to workaround this, and after discussion isc-dhcp upstream doesn't want to rely on kernel for randomization. There is no realtime configuration to disable the feature or workaround this. The only possible way is at compile time. I also talk with upstream maintainers, and there is no way they will accept to reduce the range (1024-65535) for security reason. Reducing the port range may facilitate the spoofing. Xenial has separated dhclient in two packages : isc-dhcp-client pkg : dhclient with DDNS functionality disabled (no random extra ports) isc-dhcp-client-ddns : dhclient with DDNS functionality enabled (with random extra ports) The goal here is to reproduce the same situation in Trusty, for this bug to be less painful for at least users that doesn't require DDNS functionnality. [Test Case] Run a Trusty image with following package : isc-dhcp-client isc-dhcp-common ``` dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <--- extra random port dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <--- extra random port ``` [Regression Potential] I did the split such that Trusty users will automatically get "isc- dhcp-client-ddns" installed but users bothered by this bug will have the option to switch to "isc-dhcp-client-noddns". Existing Trusty users can continue to use this DDNS functionality after the SRU without any necessary intervention. With isc-dhcp-client: dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <--- extra random port dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <--- extra random port With isc-dhcp-client-noddns : dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc Xenial also has both distinct dhclient binary package but in the opposite way. We have decided to use the opposite way approach for not impacting actual Trusty users by changing the nature of isc-dhcp- client itself. Caribou and I, slashd, have also tested a couple of release upgrades from Trusty to Xenial with both scenarios : 1 - Trusty upgrade to Xenial with "isc-dhcp-client-ddns" 2 - Trusty upgrade to Xenial with "isc-dhcp-client-noddns" and both scenarios worked as expected for caribou and I. (See comment #42) Results : === ** Upgrade tested with isc-dhcp-client ** # dpkg -l ii isc-dhcp-client 4.2.4-7ubuntu12.8 amd64ISC DHCP client ii isc-dhcp-common 4.2.4-7ubuntu12.8 amd64common files used by all the isc-dhcp* packages # netstat -anputa | grep -i dhclient udp0 0 0.0.0.0:20114 0.0.0.0:* 632/dhclient udp0 0 0.0.0.0:68 0.0.0.0:* 632/dhclient udp6 0 0 :::52249:::* 632/dhclient After successful upgrade Trusty (14.04.5) -> Xenial (16.04.2) ii isc-dhcp-client 4.3.3-5ubuntu12.7 amd64DHCP client for automatically obtaining an IP address ii isc-dhcp-common 4.3.3-5ubuntu12.7 amd64common files used by all of the isc-dhcp packages # netstat -anputa | grep -i dhclient udp0 0 0.0.0.0:68 0.0.0.0:* 633/dhclient
[Touch-packages] [Bug 1670303] Re: dhcpd does not respect ip_local_port _range or ip_local_reserved_ports
IMHO this is an important bug because it randomly interferes with other applications - lots of which use defined ports above 1024. My recent case caused an OpenVPN instance to fail to start. More seriously it created a security risk since the port in question was of course open on the firewall for purposes of the VPN, and an outsider could have used it to fire data at dhcpd with who knows what results. There is the same issue with isc-dhcp-client; per https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1176046 it seems the folks at ISC are unwilling to respect the defined dynamic port range, and they should be persuaded. Rather than allowing the kernel to assign a random port number like most applications, they want to do it "by self". The solution for that bug was to split isc-dhcp-client into two versions, one compiled with and one without ddns support. That could also be done with dhcpd, however, in my opinion it's an ugly solution. If we are going to have to just live with random ports starting from 1024, it would make a LOT more sense to alter the effect of ddns-update- style none (and ddns-updates off) so that dhcpd does NOT bind to random ports when those config parameters dictate that the random ports are never going to be used anyway. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1670303 Title: dhcpd does not respect ip_local_port _range or ip_local_reserved_ports Status in isc-dhcp package in Ubuntu: Confirmed Bug description: When isc-dhcp-server starts up, in addition to listening on port 67, it binds to a random UDP port on an IPv4 socket and another on an IPv6 socket: # netstat -naup | grep dhcp udp0 0 0.0.0.0:11075 0.0.0.0:* 8188/dhcpd udp0 0 0.0.0.0:67 0.0.0.0:* 8188/dhcpd udp6 0 0 :::10800:::* 8188/dhcpd # (I am guessing this is for making outbound DNS queries?) However, this prevented a later application of mine from working, as it wanted to bind to port 11075 for accepting incoming data. Simply doing "service isc-dhcp-server restart" makes it choose new ports, but this problem may occur again in the future. In the default configuration, I believe ephemeral ports should only use 32768 and above: # cat /proc/sys/net/ipv4/ip_local_port_range 3276860999 # cat /proc/sys/net/ipv4/ip_local_reserved_ports # I also tried setting a reservation, and this was not respected either. # sysctl net.ipv4.ip_local_reserved_ports="1-5" net.ipv4.ip_local_reserved_ports = 1-5 After restarting dhcpd: # netstat -naup | grep dhcp udp0 0 0.0.0.0:50610 0.0.0.0:* 4592/dhcpd udp0 0 0.0.0.0:67 0.0.0.0:* 4592/dhcpd udp6 0 0 :::28891:::* 4592/dhcpd I can find no way to tell isc-dhcp-server which port range to use. Setting "omapi-port" in dhcpd.conf makes it listen for *TCP* connections on the given port, and does not affect the UDP behaviour. I don't know if this is a problem with the application (explicitly picking a local port), the resolver library (ditto), or the kernel (ignoring its own ip_local_port_range) ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: isc-dhcp-server 4.3.3-5ubuntu12.6 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 Date: Mon Mar 6 09:30:29 2017 DhServerLeases: InstallationDate: Installed on 2017-03-04 (2 days ago) InstallationMedia: Ubuntu-Server 16.04.2 LTS "Xenial Xerus" - Release amd64 (20170215.8) ProcEnviron: SHELL=/bin/bash TERM=xterm-256color PATH=(custom, no user) LANG=en_US LANGUAGE=en_US: SourcePackage: isc-dhcp UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.dhcp.dhcpd.conf: 2017-03-04T09:46:07.987046 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1670303/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp