[Touch-packages] [Bug 1901373] Re: isc-dhcp-server AppArmor Denied on /proc/sys/net/ipv4/ip_local_port_range

2021-05-19 Thread Norman Henderson
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

2021-05-19 Thread Norman Henderson
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

2018-02-12 Thread Norman Henderson
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

2017-05-10 Thread Norman Henderson
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

2017-05-10 Thread Norman Henderson
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