[Touch-packages] [Bug 1902236] Re: Duplicated root and nobody returned by getent on Focal

2021-03-08 Thread Simon Déziel
Verification procedure on Focal:

$ lxc launch focal lp1902236-f
Creating lp1902236-f
Starting lp1902236-f
$ lxc exec lp1902236-f bash
root@lp1902236-f:~# getent passwd | grep root
root:x:0:0:root:/root:/bin/bash
root:x:0:0:root:/root:/bin/sh
root@lp1902236-f:~# getent passwd | grep nobody
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/:/usr/sbin/nologin

# Enable proposed
root@lp1902236-f:~# vim /etc/apt/sources.list

root@lp1902236-f:~# apt update && apt-get dist-upgrade
Calculating upgrade... Done
The following packages will be upgraded:
   libnss-systemd (245.4-4ubuntu3.4 => 245.4-4ubuntu3.5)
   libpam-systemd (245.4-4ubuntu3.4 => 245.4-4ubuntu3.5)
   libsystemd0 (245.4-4ubuntu3.4 => 245.4-4ubuntu3.5)
   libudev1 (245.4-4ubuntu3.4 => 245.4-4ubuntu3.5)
   systemd (245.4-4ubuntu3.4 => 245.4-4ubuntu3.5)
   systemd-sysv (245.4-4ubuntu3.4 => 245.4-4ubuntu3.5)
   systemd-timesyncd (245.4-4ubuntu3.4 => 245.4-4ubuntu3.5)
   udev (245.4-4ubuntu3.4 => 245.4-4ubuntu3.5)
8 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 5845 kB of archives.
After this operation, 15.4 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 libnss-systemd 
amd64 245.4-4ubuntu3.5 [95.8 kB]
Get:2 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 udev amd64 
245.4-4ubuntu3.5 [1366 kB]
Get:3 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 libudev1 amd64 
245.4-4ubuntu3.5 [81.2 kB]
Get:4 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 systemd-sysv 
amd64 245.4-4ubuntu3.5 [10.3 kB]
Get:5 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 
systemd-timesyncd amd64 245.4-4ubuntu3.5 [28.1 kB]
Get:6 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 libpam-systemd 
amd64 245.4-4ubuntu3.5 [186 kB]
Get:7 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 systemd amd64 
245.4-4ubuntu3.5 [3805 kB]
Get:8 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 libsystemd0 
amd64 245.4-4ubuntu3.5 [274 kB]
Fetched 5845 kB in 2s (2391 kB/s)
...
Setting up libnss-systemd:amd64 (245.4-4ubuntu3.5) ...
Setting up libpam-systemd:amd64 (245.4-4ubuntu3.5) ...
Processing triggers for libc-bin (2.31-0ubuntu9.2) ...
Processing triggers for dbus (1.12.16-2ubuntu2.1) ...

root@lp1902236-f:~# getent passwd | grep root
root:x:0:0:root:/root:/bin/bash
root@lp1902236-f:~# getent passwd | grep nobody
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin

** Tags removed: verification-needed verification-needed-focal
** Tags added: verification-done verification-done-focal

-- 
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/1902236

Title:
  Duplicated root and nobody returned by getent on Focal

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed

Bug description:
  [impact]

  getent password or getent group returns duplicate, false/synthesized,
  entries for root and nobody

  [test case]

  root@lp1902236-f:~# getent passwd | grep root
  root:x:0:0:root:/root:/bin/bash
  root:x:0:0:root:/root:/bin/sh
  root@lp1902236-f:~# getent group | grep root
  root:x:0:
  root:x:0:

  root@lp1902236-f:~# getent passwd | grep nobody
  nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
  nobody:x:65534:65534:nobody:/:/usr/sbin/nologin
  root@lp1902236-f:~# getent group | grep nogroup
  nogroup:x:65534:
  nogroup:x:65534:

  [regression potential]

  any regression would likely result in incorrect results to calls to
  getent or other programs using libnss-systemd

  [scope]

  this is needed only for f

  this was fixed upstream by commit
  9494da41c271bb9519d3484b6016526a72cc6be5 which was included first in
  v246, so this is fixed in g and later already.

  b and earlier doesn't show the duplication.

  [original description]

  * Summary

  systemd's NSS integration causes getent passwd/group to return
  duplicated entries for root/root and nobody/nogroup. The root account
  also gets a different shell (/bin/sh instead of /bin/bash).

  * Steps to reproduce:

  1) create a container
  $ lxc launch images:ubuntu/focal test-nobody
  2) check the root and nobody accounts
  $ lxc exec test-nobody -- getent passwd | grep -E '^(root|nobody):'
  3) check the root and nogroup groups
  $ lxc exec test-nobody -- getent group | grep -E '^(root|nogroup):'

  2 and 3 should report a single entry for each account/group but they
  return dups like this:

  root:x:0:0:root:/root:/bin/bash
  nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
  root:x:0:0:root:/root:/bin/sh
  nobody:x:65534:65534:nobody:/:/usr/sbin/nologin

  * Description

  The problem seems to come from the NSS integration:

  $ lxc exec test-nobody -- grep -wF systemd /etc/nsswitch.conf

[Touch-packages] [Bug 1787396] Re: ss crashes when using --no-header

2021-03-01 Thread Simon Déziel
*** This bug is a duplicate of bug 1913187 ***
https://bugs.launchpad.net/bugs/1913187

** This bug has been marked a duplicate of bug 1913187
   iproute2 segfaults when filtering sockets

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iproute2 in Ubuntu.
https://bugs.launchpad.net/bugs/1787396

Title:
  ss crashes when using --no-header

Status in iproute2 package in Ubuntu:
  Fix Released
Status in iproute2 source package in Bionic:
  Confirmed

Bug description:
  Steps to reproduce:

  1) Listen on port 8989:
  $ nc -l 8989 &

  2) Check that ss can list this listener:
  $ ss --no-header -nto state listening 'sport = 8989'
  010.0.0.0:8989  0.0.0.0:*

  3) Ask ss to list listeners on a port where nothing listens
  $ kill %1 # stops nc
  $ ss --no-header -nto state listening 'sport = 8989'
  Segmentation fault (core dumped)

  In the above, removing "--no-header" avoids the segfault.

  
  Additional information:

  $ lsb_release -rd
  Description:  Ubuntu 18.04.1 LTS
  Release:  18.04
  $ apt-cache policy iproute2
  iproute2:
Installed: 4.15.0-2ubuntu1
Candidate: 4.15.0-2ubuntu1
Version table:
   *** 4.15.0-2ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages
  100 /var/lib/dpkg/status

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: iproute2 4.15.0-2ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-32.35-generic 4.15.18
  Uname: Linux 4.15.0-32-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Aug 16 08:17:52 2018
  InstallationDate: Installed on 2018-07-15 (32 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180714)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_CA.UTF-8
   SHELL=/bin/bash
  SourcePackage: iproute2
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1787396/+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 1912855] Re: debugfs shouldn't be mounted by default

2021-01-22 Thread Simon Déziel
However, lxd seems to deal with /sys/kernel/debug itself by mounting it
unconditionally, irrespective of what systemd would do.

This was tested by running `systemctl mask sys-kernel-debug.mount` in a
container and seeing /sys/kernel/debug being mounted nevertheless.

-- 
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/1912855

Title:
  debugfs shouldn't be mounted by default

Status in systemd package in Ubuntu:
  New

Bug description:
  On modern Ubuntu systems, /sys/kernel/debug is mounted by default due
  to sys-kernel-debug.mount being enabled by default.

  AFAIK, this FS doesn't need to be mounted for normal operations and
  back in the day, there were concerns about the security implications
  of having it enabled/mounted by default
  (https://lists.ubuntu.com/archives/kernel-
  team/2011-January/013418.html).

  Would it be possible to not have it mounted by default?

  
  $ apt-cache policy systemd
  systemd:
Installed: 245.4-4ubuntu3.4
Candidate: 245.4-4ubuntu3.4
Version table:
   *** 245.4-4ubuntu3.4 500
  500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   245.4-4ubuntu3 500
  500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages
  $ lsb_release -rd
  Description:  Ubuntu 20.04.1 LTS
  Release:  20.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1912855/+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 1912855] [NEW] debugfs shouldn't be mounted by default

2021-01-22 Thread Simon Déziel
Public bug reported:

On modern Ubuntu systems, /sys/kernel/debug is mounted by default due to
sys-kernel-debug.mount being enabled by default.

AFAIK, this FS doesn't need to be mounted for normal operations and back
in the day, there were concerns about the security implications of
having it enabled/mounted by default (https://lists.ubuntu.com/archives
/kernel-team/2011-January/013418.html).

Would it be possible to not have it mounted by default?


$ apt-cache policy systemd
systemd:
  Installed: 245.4-4ubuntu3.4
  Candidate: 245.4-4ubuntu3.4
  Version table:
 *** 245.4-4ubuntu3.4 500
500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 
Packages
100 /var/lib/dpkg/status
 245.4-4ubuntu3 500
500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages
$ lsb_release -rd
Description:Ubuntu 20.04.1 LTS
Release:20.04

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Status: New

-- 
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/1912855

Title:
  debugfs shouldn't be mounted by default

Status in systemd package in Ubuntu:
  New

Bug description:
  On modern Ubuntu systems, /sys/kernel/debug is mounted by default due
  to sys-kernel-debug.mount being enabled by default.

  AFAIK, this FS doesn't need to be mounted for normal operations and
  back in the day, there were concerns about the security implications
  of having it enabled/mounted by default
  (https://lists.ubuntu.com/archives/kernel-
  team/2011-January/013418.html).

  Would it be possible to not have it mounted by default?

  
  $ apt-cache policy systemd
  systemd:
Installed: 245.4-4ubuntu3.4
Candidate: 245.4-4ubuntu3.4
Version table:
   *** 245.4-4ubuntu3.4 500
  500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   245.4-4ubuntu3 500
  500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages
  $ lsb_release -rd
  Description:  Ubuntu 20.04.1 LTS
  Release:  20.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1912855/+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 1902236] [NEW] Duplicated root and nobody returned by getent on Focal

2020-10-30 Thread Simon Déziel
Public bug reported:

* Summary

systemd's NSS integration causes getent passwd/group to return
duplicated entries for root/root and nobody/nogroup. The root account
also gets a different shell (/bin/sh instead of /bin/bash).

* Steps to reproduce:

1) create a container
$ lxc launch images:ubuntu/focal test-nobody
2) check the root and nobody accounts
$ lxc exec test-nobody -- getent passwd | grep -E '^(root|nobody):'
3) check the root and nogroup groups
$ lxc exec test-nobody -- getent group | grep -E '^(root|nogroup):'

2 and 3 should report a single entry for each account/group but they
return dups like this:

root:x:0:0:root:/root:/bin/bash
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
root:x:0:0:root:/root:/bin/sh
nobody:x:65534:65534:nobody:/:/usr/sbin/nologin

* Description

The problem seems to come from the NSS integration:

$ lxc exec test-nobody -- grep -wF systemd /etc/nsswitch.conf
passwd: files systemd
group:  files systemd

as the /etc/passwd and /etc/group file contain no dups:

$ lxc exec test-nobody -- grep ^nobody: /etc/passwd
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
$ lxc exec test-nobody -- grep ^nogroup: /etc/group
nogroup:x:65534:

Removing systemd from /etc/nsswitch.conf indeed removes the dup.

An alternative way of seeing what systemd adds on top of the flat files:

$ lxc exec test-nobody -- bash -c 'diff -u /etc/passwd <(getent passwd)'
--- /etc/passwd 2020-10-30 13:07:52.219261001 +
+++ /dev/fd/63  2020-10-30 13:29:38.396928732 +
@@ -24,3 +24,5 @@
 _apt:x:105:65534::/nonexistent:/usr/sbin/nologin
 ubuntu:x:1000:1000::/home/ubuntu:/bin/bash
 systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
+root:x:0:0:root:/root:/bin/sh
+nobody:x:65534:65534:nobody:/:/usr/sbin/nologin

$ lxc exec test-nobody -- bash -c 'diff -u /etc/group <(getent group)'
--- /etc/group  2020-10-30 13:07:52.211261089 +
+++ /dev/fd/63  2020-10-30 13:29:45.892846747 +
@@ -50,3 +50,5 @@
 ubuntu:x:1000:
 ssh:x:111:
 systemd-coredump:x:999:
+root:x:0:
+nogroup:x:65534:

* Additional information

This bug seems to occur on Focal alone as Bionic and Groovy are not
affected.

$ lsb_release -rd
Description:Ubuntu 20.04.1 LTS
Release:20.04

$ apt-cache policy base-passwd systemd
base-passwd:
  Installed: 3.5.47
  Candidate: 3.5.47
  Version table:
 *** 3.5.47 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status
systemd:
  Installed: 245.4-4ubuntu3.2
  Candidate: 245.4-4ubuntu3.2
  Version table:
 *** 245.4-4ubuntu3.2 500
500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
100 /var/lib/dpkg/status
 245.4-4ubuntu3 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Status: New

** Description changed:

  * Summary
  
  systemd's NSS integration causes getent passwd/group to return
  duplicated entries for root/root and nobody/nogroup. The root account
  also gets a different shell (/bin/sh instead of /bin/bash).
  
  * Steps to reproduce:
  
  1) create a container
  $ lxc launch images:ubuntu/focal test-nobody
  2) check the root and nobody accounts
  $ lxc exec test-nobody -- getent passwd | grep -E '^(root|nobody):'
  3) check the root and nogroup groups
  $ lxc exec test-nobody -- getent group | grep -E '^(root|nogroup):'
  
  2 and 3 should report a single entry for each account/group but they
  return dups like this:
  
  root:x:0:0:root:/root:/bin/bash
  nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
  root:x:0:0:root:/root:/bin/sh
  nobody:x:65534:65534:nobody:/:/usr/sbin/nologin
- 
  
  * Description
  
  The problem seems to come from the NSS integration:
  
  $ lxc exec test-nobody -- grep -wF systemd /etc/nsswitch.conf
  passwd: files systemd
  group:  files systemd
  
  as the /etc/passwd and /etc/group file contain no dups:
  
  $ lxc exec test-nobody -- grep ^nobody: /etc/passwd
  nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
  $ lxc exec test-nobody -- grep ^nogroup: /etc/group
  nogroup:x:65534:
  
  Removing systemd from /etc/nsswitch.conf indeed removes the dup.
  
  An alternative way of seeing what systemd adds on top of the flat files:
  
  $ lxc exec test-nobody -- bash -c 'diff -u /etc/passwd <(getent passwd)'
  --- /etc/passwd   2020-10-30 13:07:52.219261001 +
  +++ /dev/fd/632020-10-30 13:29:38.396928732 +
  @@ -24,3 +24,5 @@
-  _apt:x:105:65534::/nonexistent:/usr/sbin/nologin
-  ubuntu:x:1000:1000::/home/ubuntu:/bin/bash
-  systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
+  _apt:x:105:65534::/nonexistent:/usr/sbin/nologin
+  ubuntu:x:1000:1000::/home/ubuntu:/bin/bash
+  systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
  +root:x:0:0:root:/root:/bin/sh
  +nobody:x:65534:65534:nobody:/:/usr/sbin/nologin
  
  $ lxc exec test-nobody 

[Touch-packages] [Bug 1897561] Re: libperl.so.5.30.0 causes nginx to segfault

2020-10-13 Thread Simon Déziel
** Description changed:

+ [Steps to reproduce]
+ 
+ 1) launch a focal container
+ $ lxc launch images:ubuntu/focal focal-1897561
+ 2) enter the container
+ $ lxc shell focal-1897561
+ 3) install libnginx-mod-http-perl
+ # apt-get install -y nginx-core libnginx-mod-http-perl
+ 4) check nginx journal
+ # journalctl -fu nginx &
+ 5) reload nginx 2-3 times
+ # systemctl reload nginx
+ 
+ Eventually you will see this from the journal:
+ 
+ Oct 13 17:13:34 focal-1897561 systemd[1]: Reloaded A high performance web 
server and a reverse proxy server.
+ Oct 13 17:13:35 focal-1897561 systemd[1]: nginx.service: Main process exited, 
code=dumped, status=11/SEGV
+ Oct 13 17:13:35 focal-1897561 systemd[1]: nginx.service: Killing process 588 
(nginx) with signal SIGKILL.
+ Oct 13 17:13:35 focal-1897561 systemd[1]: nginx.service: Killing process 589 
(nginx) with signal SIGKILL.
+ Oct 13 17:13:35 focal-1897561 systemd[1]: nginx.service: Killing process 588 
(nginx) with signal SIGKILL.
+ Oct 13 17:13:35 focal-1897561 systemd[1]: nginx.service: Killing process 589 
(nginx) with signal SIGKILL.
+ Oct 13 17:13:35 focal-1897561 systemd[1]: nginx.service: Failed with result 
'core-dump'.
+ 
+ 
+ [Original bug description]
+ 
  Ubuntu 20.04 LTS
  
  Looks that Perl 5.30 has bug that causes nginx to die, usually occurs
  after "service nginx reload"
  
  This looks like nginx, but it really is perl issue:
  https://github.com/Perl/perl5/issues/17154
  
  Fix done in 5.32 (Perl5 commit bf0) and people are asking backport
  to 5.30 to get fix also to nginx.
  
  Error:
  Sep 28 07:39:43 host kernel: [1340832.811014] nginx[3253005]: segfault at 10 
ip 7fbf3220d593 sp 7ffd6bba6260 error 4 in 
libperl.so.5.30.0[7fbf321a5000+166000]
  
  Symptom: Nginx terminates

** Description changed:

  [Steps to reproduce]
  
  1) launch a focal container
  $ lxc launch images:ubuntu/focal focal-1897561
  2) enter the container
  $ lxc shell focal-1897561
  3) install libnginx-mod-http-perl
  # apt-get install -y nginx-core libnginx-mod-http-perl
  4) check nginx journal
  # journalctl -fu nginx &
  5) reload nginx 2-3 times
  # systemctl reload nginx
  
  Eventually you will see this from the journal:
  
  Oct 13 17:13:34 focal-1897561 systemd[1]: Reloaded A high performance web 
server and a reverse proxy server.
  Oct 13 17:13:35 focal-1897561 systemd[1]: nginx.service: Main process exited, 
code=dumped, status=11/SEGV
  Oct 13 17:13:35 focal-1897561 systemd[1]: nginx.service: Killing process 588 
(nginx) with signal SIGKILL.
  Oct 13 17:13:35 focal-1897561 systemd[1]: nginx.service: Killing process 589 
(nginx) with signal SIGKILL.
  Oct 13 17:13:35 focal-1897561 systemd[1]: nginx.service: Killing process 588 
(nginx) with signal SIGKILL.
  Oct 13 17:13:35 focal-1897561 systemd[1]: nginx.service: Killing process 589 
(nginx) with signal SIGKILL.
  Oct 13 17:13:35 focal-1897561 systemd[1]: nginx.service: Failed with result 
'core-dump'.
  
+ [Workaround]
+ 
+ If libnginx-mod-http-perl is not needed, purging it and restarting nginx
+ sidesteps the problem.
  
  [Original bug description]
  
  Ubuntu 20.04 LTS
  
  Looks that Perl 5.30 has bug that causes nginx to die, usually occurs
  after "service nginx reload"
  
  This looks like nginx, but it really is perl issue:
  https://github.com/Perl/perl5/issues/17154
  
  Fix done in 5.32 (Perl5 commit bf0) and people are asking backport
  to 5.30 to get fix also to nginx.
  
  Error:
  Sep 28 07:39:43 host kernel: [1340832.811014] nginx[3253005]: segfault at 10 
ip 7fbf3220d593 sp 7ffd6bba6260 error 4 in 
libperl.so.5.30.0[7fbf321a5000+166000]
  
  Symptom: Nginx terminates

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to perl in Ubuntu.
https://bugs.launchpad.net/bugs/1897561

Title:
  libperl.so.5.30.0 causes nginx to segfault

Status in perl package in Ubuntu:
  Incomplete

Bug description:
  [Steps to reproduce]

  1) launch a focal container
  $ lxc launch images:ubuntu/focal focal-1897561
  2) enter the container
  $ lxc shell focal-1897561
  3) install libnginx-mod-http-perl
  # apt-get install -y nginx-core libnginx-mod-http-perl
  4) check nginx journal
  # journalctl -fu nginx &
  5) reload nginx 2-3 times
  # systemctl reload nginx

  Eventually you will see this from the journal:

  Oct 13 17:13:34 focal-1897561 systemd[1]: Reloaded A high performance web 
server and a reverse proxy server.
  Oct 13 17:13:35 focal-1897561 systemd[1]: nginx.service: Main process exited, 
code=dumped, status=11/SEGV
  Oct 13 17:13:35 focal-1897561 systemd[1]: nginx.service: Killing process 588 
(nginx) with signal SIGKILL.
  Oct 13 17:13:35 focal-1897561 systemd[1]: nginx.service: Killing process 589 
(nginx) with signal SIGKILL.
  Oct 13 17:13:35 focal-1897561 systemd[1]: nginx.service: Killing process 588 
(nginx) with signal SIGKILL.
  Oct 13 17:13:35 focal-1897561 systemd[1]: nginx.service: Killing 

[Touch-packages] [Bug 1891215] Re: systemd-resolved re-creates /run/systemd/resolve/*resolv.conf for every IPv6 RA received

2020-08-11 Thread Simon Déziel
strace'ing systemd-resolved showed that files under
/run/systemd/netif/links/ are re-created as well when a RA comes in but
their content never changes yet the stub-resolv.conf is created over and
over:

root@lxd02:~# cat /run/systemd/netif/links/* 
/run/systemd/resolve/stub-resolv.conf | md5sum; stat -c "%i" 
/run/systemd/resolve/stub-resolv.conf
4cec911154fd89fd31b3e4c96894aad7  -
625
root@lxd02:~# cat /run/systemd/netif/links/* 
/run/systemd/resolve/stub-resolv.conf | md5sum; stat -c "%i" 
/run/systemd/resolve/stub-resolv.conf
4cec911154fd89fd31b3e4c96894aad7  -
624
root@lxd02:~# cat /run/systemd/netif/links/* 
/run/systemd/resolve/stub-resolv.conf | md5sum; stat -c "%i" 
/run/systemd/resolve/stub-resolv.conf
4cec911154fd89fd31b3e4c96894aad7  -
625
root@lxd02:~# cat /run/systemd/netif/links/* 
/run/systemd/resolve/stub-resolv.conf | md5sum; stat -c "%i" 
/run/systemd/resolve/stub-resolv.conf
4cec911154fd89fd31b3e4c96894aad7  -
625
root@lxd02:~# cat /run/systemd/netif/links/* 
/run/systemd/resolve/stub-resolv.conf | md5sum; stat -c "%i" 
/run/systemd/resolve/stub-resolv.conf
4cec911154fd89fd31b3e4c96894aad7  -
624
root@lxd02:~# cat /run/systemd/netif/links/* 
/run/systemd/resolve/stub-resolv.conf | md5sum; stat -c "%i" 
/run/systemd/resolve/stub-resolv.conf
4cec911154fd89fd31b3e4c96894aad7  -
625

-- 
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/1891215

Title:
  systemd-resolved re-creates /run/systemd/resolve/*resolv.conf for
  every IPv6 RA received

Status in systemd package in Ubuntu:
  New

Bug description:
  # Issue description:

  On 2 Linode VMs that are used as lxd hosts, we noticed that
  /run/systemd/resolve/*resolv.conf were re-created quite frequently (~
  once per second). We noticed because of the log noise from lxd's
  dnsmasq instance using inotify to watch the target of /etc/resolv.conf
  (which points to the stub-resolv.conf in our case). This was (wrongly)
  reported as a lxd bug (https://github.com/lxc/lxd/issues/7765) until
  it became apparent it was more likely to be a problem with
  systemd(-resolved)?.

  The log noise is the observable problem that would be nice to see
  addressed:

root@lxd02:~# uptime
 17:55:48 up  9:52,  1 user,  load average: 0.18, 0.11, 0.05
root@lxd02:~# journalctl -b0 | grep -cF dnsmasq
158609

  Upon further investigation, it seems that systemd-resolved re-creates
  the resolv.conf and stub-resolv.conf files whenever an IPv6 RA is
  received.

  1) One can observe that by setting systemd-resolved's service in debug
  mode:

  $ sudo systemctl edit systemd-resolved

  and in the editor that is opened, add and save this content:

  [Service]
  Environment=SYSTEMD_LOG_LEVEL=debug

  then restart systemd-resolved and watch the logs scroll by with:

  $ journalctl -fu systemd-resolved

  3) In another terminal, watch the files be recreated with:

  watch -d -n 0.1 stat /run/systemd/resolve/stub-resolv.conf

  3) In yet another terminal, run a packet capture and watch "ICMP6,
  router advertisement" messages come by:

  sudo tcpdump -ni eth0 icmp6

  
  You will see that every time a RA packet comes in, resolved's journal will 
log this:

Aug 11 17:33:55 lxd02 systemd-resolved[15368]: Sent message
  type=signal sender=n/a destination=n/a path=/org/freedesktop/resolve1
  interface=org.freedesktop.DBus.Properties member=PropertiesChanged
  cookie=244 reply_cookie=0 signature=sa{sv}as error-name=n/a error-
  message=n/a

  And the stat monitoring terminal will blink to highlight the new inode
  and timestamps of the freshly replaced stub-resolv.conf file.

  
  # Additional information:

  root@lxd02:~# lsb_release -rd
  Description:  Ubuntu 20.04.1 LTS
  Release:  20.04

  root@lxd02:~# apt-cache policy systemd
  systemd:
Installed: 245.4-4ubuntu3.2
Candidate: 245.4-4ubuntu3.2
Version table:
   *** 245.4-4ubuntu3.2 500
  500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
  100 /var/lib/dpkg/status
   245.4-4ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages

  root@lxd02:~# uname -a
  Linux lxd01 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 
x86_64 x86_64 x86_64 GNU/Linux

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1891215/+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 1891215] [NEW] systemd-resolved re-creates /run/systemd/resolve/*resolv.conf for every IPv6 RA received

2020-08-11 Thread Simon Déziel
Public bug reported:

# Issue description:

On 2 Linode VMs that are used as lxd hosts, we noticed that
/run/systemd/resolve/*resolv.conf were re-created quite frequently (~
once per second). We noticed because of the log noise from lxd's dnsmasq
instance using inotify to watch the target of /etc/resolv.conf (which
points to the stub-resolv.conf in our case). This was (wrongly) reported
as a lxd bug (https://github.com/lxc/lxd/issues/7765) until it became
apparent it was more likely to be a problem with systemd(-resolved)?.

The log noise is the observable problem that would be nice to see
addressed:

  root@lxd02:~# uptime
   17:55:48 up  9:52,  1 user,  load average: 0.18, 0.11, 0.05
  root@lxd02:~# journalctl -b0 | grep -cF dnsmasq
  158609

Upon further investigation, it seems that systemd-resolved re-creates
the resolv.conf and stub-resolv.conf files whenever an IPv6 RA is
received.

1) One can observe that by setting systemd-resolved's service in debug
mode:

$ sudo systemctl edit systemd-resolved

and in the editor that is opened, add and save this content:

[Service]
Environment=SYSTEMD_LOG_LEVEL=debug

then restart systemd-resolved and watch the logs scroll by with:

$ journalctl -fu systemd-resolved

3) In another terminal, watch the files be recreated with:

watch -d -n 0.1 stat /run/systemd/resolve/stub-resolv.conf

3) In yet another terminal, run a packet capture and watch "ICMP6,
router advertisement" messages come by:

sudo tcpdump -ni eth0 icmp6


You will see that every time a RA packet comes in, resolved's journal will log 
this:

  Aug 11 17:33:55 lxd02 systemd-resolved[15368]: Sent message
type=signal sender=n/a destination=n/a path=/org/freedesktop/resolve1
interface=org.freedesktop.DBus.Properties member=PropertiesChanged
cookie=244 reply_cookie=0 signature=sa{sv}as error-name=n/a error-
message=n/a

And the stat monitoring terminal will blink to highlight the new inode
and timestamps of the freshly replaced stub-resolv.conf file.


# Additional information:

root@lxd02:~# lsb_release -rd
Description:Ubuntu 20.04.1 LTS
Release:20.04

root@lxd02:~# apt-cache policy systemd
systemd:
  Installed: 245.4-4ubuntu3.2
  Candidate: 245.4-4ubuntu3.2
  Version table:
 *** 245.4-4ubuntu3.2 500
500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
100 /var/lib/dpkg/status
 245.4-4ubuntu3 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages

root@lxd02:~# uname -a
Linux lxd01 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 
x86_64 x86_64 GNU/Linux

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Status: New

-- 
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/1891215

Title:
  systemd-resolved re-creates /run/systemd/resolve/*resolv.conf for
  every IPv6 RA received

Status in systemd package in Ubuntu:
  New

Bug description:
  # Issue description:

  On 2 Linode VMs that are used as lxd hosts, we noticed that
  /run/systemd/resolve/*resolv.conf were re-created quite frequently (~
  once per second). We noticed because of the log noise from lxd's
  dnsmasq instance using inotify to watch the target of /etc/resolv.conf
  (which points to the stub-resolv.conf in our case). This was (wrongly)
  reported as a lxd bug (https://github.com/lxc/lxd/issues/7765) until
  it became apparent it was more likely to be a problem with
  systemd(-resolved)?.

  The log noise is the observable problem that would be nice to see
  addressed:

root@lxd02:~# uptime
 17:55:48 up  9:52,  1 user,  load average: 0.18, 0.11, 0.05
root@lxd02:~# journalctl -b0 | grep -cF dnsmasq
158609

  Upon further investigation, it seems that systemd-resolved re-creates
  the resolv.conf and stub-resolv.conf files whenever an IPv6 RA is
  received.

  1) One can observe that by setting systemd-resolved's service in debug
  mode:

  $ sudo systemctl edit systemd-resolved

  and in the editor that is opened, add and save this content:

  [Service]
  Environment=SYSTEMD_LOG_LEVEL=debug

  then restart systemd-resolved and watch the logs scroll by with:

  $ journalctl -fu systemd-resolved

  3) In another terminal, watch the files be recreated with:

  watch -d -n 0.1 stat /run/systemd/resolve/stub-resolv.conf

  3) In yet another terminal, run a packet capture and watch "ICMP6,
  router advertisement" messages come by:

  sudo tcpdump -ni eth0 icmp6

  
  You will see that every time a RA packet comes in, resolved's journal will 
log this:

Aug 11 17:33:55 lxd02 systemd-resolved[15368]: Sent message
  type=signal sender=n/a destination=n/a path=/org/freedesktop/resolve1
  interface=org.freedesktop.DBus.Properties member=PropertiesChanged
  cookie=244 reply_cookie=0 signature=sa{sv}as error-name=n/a error-
  message=n/a

  And the stat monitoring terminal will blink to highlight the new inode
  and 

[Touch-packages] [Bug 1857036] Re: `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE): Operation not permitted` error when run inside a container.

2020-07-21 Thread Simon Déziel
[Test Case]
$ lxc launch ubuntu:20.04/amd64 sudo-sru-lp1857036-test
$ lxc shell sudo-sru-lp1857036-test

Reproduce the problem

root@sudo-sru-lp1857036-test:~# sudo true
sudo: setrlimit(RLIMIT_CORE): Operation not permitted

Enable -proposed and update

root@sudo-sru-lp1857036-test:~# apt install -V sudo
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be upgraded:
   sudo (1.8.31-1ubuntu1 => 1.8.31-1ubuntu1.1)
1 upgraded, 0 newly installed, 0 to remove and 17 not upgraded.
Need to get 513 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 sudo amd64 
1.8.31-1ubuntu1.1 [513 kB]
Fetched 513 kB in 1s (576 kB/s)
(Reading database ... 14621 files and directories currently installed.)
Preparing to unpack .../sudo_1.8.31-1ubuntu1.1_amd64.deb ...
Unpacking sudo (1.8.31-1ubuntu1.1) over (1.8.31-1ubuntu1) ...
Setting up sudo (1.8.31-1ubuntu1.1) ...

Check if the fix works

root@sudo-sru-lp1857036-test:~# sudo true
root@sudo-sru-lp1857036-test:~# 

** Tags removed: verification-needed verification-needed-focal
** Tags added: verification-done verification-done-focal

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to sudo in Ubuntu.
https://bugs.launchpad.net/bugs/1857036

Title:
  `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE):
  Operation not permitted` error when run inside a container.

Status in sudo package in Ubuntu:
  Fix Released
Status in sudo source package in Focal:
  Fix Committed
Status in sudo source package in Groovy:
  Fix Released

Bug description:
  [Impact]
  Logging in as a sudo user in a Ubuntu Focal Linux container displays a
  warning:

    sudo: setrlimit(RLIMIT_CORE): Operation not permitted

  The warning is entirely unnecessary - the container is trying to adjust
  RLIMIT_CORE, but this isn't allowed inside a container anyway.

  While this is "just" a warning, logging into a container as sudo is a
  very common practice, so this warning risks creating confusion for LTS
  users.

  [Test Case]
  $ lxc launch ubuntu:20.04/amd64 sudo-sru-lp1857036-test
  $ lxc shell sudo-sru-lp1857036-test

  # sudo --login --user ubuntu
  sudo: setrlimit(RLIMIT_CORE): Operation not permitted
  To run a command as administrator (user "root"), use "sudo ".
  See "man sudo_root" for details.
  $ logout

  Enable -proposed and update
  # apt-get install sudo

  # sudo --login --user ubuntu
  $

  [Regression Potential]
  As this only affects printing of a couple warnings, the only behavioral
  change is in stderr output.

  [Discussion]
  This changes a couple warnings into equivalent debug printfs, which
  brings the sudo behavior in-line with the behavior in groovy, bionic,
  etc. and should cause no troubles.

  This patch originates from upstream, and is already in groovy's sudo
  package (which thus can be seen not to exhibit the issue).

  The upstream patch includes some new debug prints which should be
  harmless but are unnecessary to the fix so they've been removed.

  [Original Report]
  When using `sudo --login --user USERNAME` with Ubuntu Focal currently, it 
will correctly operate but it will also throw the following error before 
continuing with the logon process (which completes successfully except for the 
stated error):

  sudo: setrlimit(RLIMIT_CORE): Operation not permitted

  A full run of this was tested in a Focal LXD container after dropping
  to a root shell to reproduce (arstotzka is the host system, focal-test
  is the test container):

  teward@arstotzka:~$ lxc shell focal-test
  root@focal-test:~# sudo --login --user ubuntu
  sudo: setrlimit(RLIMIT_CORE): Operation not permitted
  To run a command as administrator (user "root"), use "sudo ".
  See "man sudo_root" for details.

  ubuntu@focal-test:~$

  This appears to be similar to this issue identified on RedHat's
  tracker: https://bugzilla.redhat.com/show_bug.cgi?id=1773148

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: sudo 1.8.29-1ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-72.81-generic 4.15.18
  Uname: Linux 4.15.0-72-generic x86_64
  ApportVersion: 2.20.11-0ubuntu14
  Architecture: amd64
  Date: Thu Dec 19 17:16:31 2019
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  SourcePackage: sudo
  UpgradeStatus: No upgrade log present (probably fresh install)
  VisudoCheck:
   /etc/sudoers: parsed OK
   /etc/sudoers.d/90-cloud-init-users: parsed OK
   /etc/sudoers.d/README: parsed OK

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1857036/+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 1857036] Re: `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE): Operation not permitted` error when run inside a container.

2020-07-20 Thread Simon Déziel
Thanks Bryce for the PPA. I can confirm it does work:

# reproduce the problem:
root@sudo-sru-lp1857036-test:~# sudo true
sudo: setrlimit(RLIMIT_CORE): Operation not permitted

# get the fix from the PPA:
root@sudo-sru-lp1857036-test:~# apt-add-repository -yus 
ppa:bryce/sudo-sru-lp1857036-setrlimit-in-lxc
Get:1 http://security.ubuntu.com/ubuntu focal-security InRelease [107 kB]
Get:2 http://ppa.launchpad.net/bryce/sudo-sru-lp1857036-setrlimit-in-lxc/ubuntu 
focal InRelease [17.6 kB]   
Hit:3 http://archive.ubuntu.com/ubuntu focal InRelease  

Get:4 http://archive.ubuntu.com/ubuntu focal-updates InRelease [111 kB]
Get:5 http://ppa.launchpad.net/bryce/sudo-sru-lp1857036-setrlimit-in-lxc/ubuntu 
focal/main Sources [864 B]
Get:6 http://ppa.launchpad.net/bryce/sudo-sru-lp1857036-setrlimit-in-lxc/ubuntu 
focal/main amd64 Packages [756 B]   
Get:7 http://ppa.launchpad.net/bryce/sudo-sru-lp1857036-setrlimit-in-lxc/ubuntu 
focal/main Translation-en [528 B]
Get:8 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages [261 
kB]
Get:9 http://archive.ubuntu.com/ubuntu focal-updates/main Translation-en [102 
kB]
Get:10 http://archive.ubuntu.com/ubuntu focal-updates/restricted amd64 Packages 
[28.4 kB]
Get:11 http://archive.ubuntu.com/ubuntu focal-updates/restricted Translation-en 
[7,560 B]
Fetched 637 kB in 2s (389 kB/s)
Reading package lists... Done
root@sudo-sru-lp1857036-test:~# apt-get install -V sudo
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be upgraded:
   sudo (1.8.31-1ubuntu1 => 1.8.31-1ubuntu2~focal1)
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,320 kB of archives.
After this operation, 1,849 kB of additional disk space will be used.
Get:1 http://ppa.launchpad.net/bryce/sudo-sru-lp1857036-setrlimit-in-lxc/ubuntu 
focal/main amd64 sudo amd64 1.8.31-1ubuntu2~focal1 [1,320 kB]
Fetched 1,320 kB in 3s (495 kB/s)
(Reading database ... 16712 files and directories currently installed.)
Preparing to unpack .../sudo_1.8.31-1ubuntu2~focal1_amd64.deb ...
Unpacking sudo (1.8.31-1ubuntu2~focal1) over (1.8.31-1ubuntu1) ...
Setting up sudo (1.8.31-1ubuntu2~focal1) ...

# confirm the fix:
root@sudo-sru-lp1857036-test:~# sudo true
root@sudo-sru-lp1857036-test:~#

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to sudo in Ubuntu.
https://bugs.launchpad.net/bugs/1857036

Title:
  `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE):
  Operation not permitted` error when run inside a container.

Status in sudo package in Ubuntu:
  Fix Released
Status in sudo source package in Focal:
  Fix Committed
Status in sudo source package in Groovy:
  Fix Released

Bug description:
  [Impact]
  Logging in as a sudo user in a Ubuntu Focal Linux container displays a
  warning:

    sudo: setrlimit(RLIMIT_CORE): Operation not permitted

  The warning is entirely unnecessary - the container is trying to adjust
  RLIMIT_CORE, but this isn't allowed inside a container anyway.

  While this is "just" a warning, logging into a container as sudo is a
  very common practice, so this warning risks creating confusion for LTS
  users.

  [Test Case]
  $ lxc launch ubuntu:20.04/amd64 sudo-sru-lp1857036-test
  $ lxc shell sudo-sru-lp1857036-test

  # sudo --login --user ubuntu
  sudo: setrlimit(RLIMIT_CORE): Operation not permitted
  To run a command as administrator (user "root"), use "sudo ".
  See "man sudo_root" for details.
  $ logout

  Install the PPA
  # apt-add-repository -yus ppa:bryce/sudo-sru-lp1857036-setrlimit-in-lxc
  # apt-get install sudo

  # sudo --login --user ubuntu
  $

  [Regression Potential]
  As this only affects printing of a couple warnings, the only behavioral
  change is in stderr output.

  [Discussion]
  This changes a couple warnings into equivalent debug printfs, which
  brings the sudo behavior in-line with the behavior in groovy, bionic,
  etc. and should cause no troubles.

  This patch originates from upstream, and is already in groovy's sudo
  package (which thus can be seen not to exhibit the issue).

  The upstream patch includes some new debug prints which should be
  harmless but are unnecessary to the fix so they've been removed.

  [Original Report]
  When using `sudo --login --user USERNAME` with Ubuntu Focal currently, it 
will correctly operate but it will also throw the following error before 
continuing with the logon process (which completes successfully except for the 
stated error):

  sudo: setrlimit(RLIMIT_CORE): Operation not permitted

  A full run of this was tested in a Focal LXD container after dropping
  to a root shell to reproduce (arstotzka is the host system, focal-test
  is the test container):

  teward@arstotzka:~$ lxc shell focal-test
  root@focal-test:~# sudo --login --user ubuntu
  sudo: 

[Touch-packages] [Bug 1867799] Re: Focal: sudo: setrlimit(RLIMIT_CORE): Operation not permitted

2020-07-20 Thread Simon Déziel
*** This bug is a duplicate of bug 1857036 ***
https://bugs.launchpad.net/bugs/1857036

** This bug has been marked a duplicate of bug 1857036
   `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE): Operation not 
permitted` error when run inside a container.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to sudo in Ubuntu.
https://bugs.launchpad.net/bugs/1867799

Title:
  Focal: sudo: setrlimit(RLIMIT_CORE): Operation not permitted

Status in juju:
  Invalid
Status in sudo package in Ubuntu:
  Confirmed

Bug description:
  When bootstrapping to focal and using debug output, we get the
  following outputted to the stderr.

  sudo: setrlimit(RLIMIT_CORE): Operation not permitted

  I'm unsure what it's attempting to do at that point, but others have
  also run into this with a suggested workaround.

  https://gitlab.alpinelinux.org/alpine/aports/issues/11122
  https://bugzilla.redhat.com/show_bug.cgi?id=1773148

To manage notifications about this bug go to:
https://bugs.launchpad.net/juju/+bug/1867799/+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 1868456] Re: "sudo: setrlimit(RLIMIT_CORE): Operation not permitted" error when using sudo in 20.04 LXD container

2020-07-20 Thread Simon Déziel
*** This bug is a duplicate of bug 1857036 ***
https://bugs.launchpad.net/bugs/1857036

** This bug has been marked a duplicate of bug 1857036
   `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE): Operation not 
permitted` error when run inside a container.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to sudo in Ubuntu.
https://bugs.launchpad.net/bugs/1868456

Title:
  "sudo: setrlimit(RLIMIT_CORE): Operation not permitted" error when
  using sudo in 20.04 LXD container

Status in lxd package in Ubuntu:
  Invalid
Status in sudo package in Ubuntu:
  Confirmed

Bug description:
  I fired up a LXD container using ubuntu-daily:f on my machine and
  every time I issue a comment inside the container using sudo, I get
  this error:

  sudo: setrlimit(RLIMIT_CORE): Operation not permitted

  I did some digging online and found this was reported against Fedora last 
fall which lead me to this bugzilla report:
  https://bugzilla.redhat.com/show_bug.cgi?id=1773148

  which seems to tie this to a change in sudo between 1.8.28 and 1.8.29.

  Focal has 1.8.31:
  bladernr@focal-builder:~/development/kernels-ubuntu/focal$ apt-cache policy 
sudo
  sudo:
    Installed: 1.8.31-1ubuntu1
    Candidate: 1.8.31-1ubuntu1
    Version table:
   *** 1.8.31-1ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status

  This is not an issue on Bionic:
  bladernr@galactica:~/development/kernels-upstream/mainline$ apt-cache policy 
sudo
  sudo:
    Installed: 1.8.21p2-3ubuntu1.2
    Candidate: 1.8.21p2-3ubuntu1.2
    Version table:
   *** 1.8.21p2-3ubuntu1.2 500
  500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   1.8.21p2-3ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages

  From the redhat bug, the described workaround does clear these
  messages up:

  # set disable_coredump false

  Once I've done that, the error messages go away.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1868456/+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 1875708] Re: Truncated messages in journald since systemd v244

2020-07-20 Thread Simon Déziel
Reproducing the issue *before* the patch:

root@foo:~# dpkg -l| grep -wF ' systemd '
ii  systemd 245.4-4ubuntu3.1  amd64system 
and service manager
root@foo:~# systemctl status test.service
● test.service - Test Truncate
 Loaded: loaded (/etc/systemd/system/test.service; enabled; vendor preset: 
enabled)
 Active: active (exited) since Mon 2020-07-20 18:08:56 UTC; 53s ago
Process: 228 ExecStart=/usr/lib/test.sh long-test-for-start (code=exited, 
status=0/SUCCESS)
   Main PID: 228 (code=exited, status=0/SUCCESS)

Jul 20 18:08:56 foo systemd[1]: Starting Test Truncate...
Jul 20 18:08:56 foo test.sh[229]: This will
Jul 20 18:08:56 foo test.sh[228]: T
Jul 20 18:08:56 foo test.sh[230]: T
Jul 20 18:08:56 foo test.sh[230]: sually fai
Jul 20 18:08:56 foo test.sh[228]: s
Jul 20 18:08:56 foo test.sh[231]: s
Jul 20 18:08:56 foo test.sh[231]: nd be truncate
Jul 20 18:08:56 foo test.sh[228]: n
Jul 20 18:08:56 foo systemd[1]: Finished Test Truncate.


Upgrading to focal-proposed version:

root@foo:~# apt-get dist-upgrade -V
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
   ...
   libnss-systemd (245.4-4ubuntu3.1 => 245.4-4ubuntu3.2)
   libpam-systemd (245.4-4ubuntu3.1 => 245.4-4ubuntu3.2)
   libseccomp2 (2.4.3-1ubuntu3.20.04.2 => 2.4.3-1ubuntu3.20.04.3)
   libsystemd0 (245.4-4ubuntu3.1 => 245.4-4ubuntu3.2)
   libudev1 (245.4-4ubuntu3.1 => 245.4-4ubuntu3.2)
   systemd (245.4-4ubuntu3.1 => 245.4-4ubuntu3.2)
   systemd-sysv (245.4-4ubuntu3.1 => 245.4-4ubuntu3.2)
   systemd-timesyncd (245.4-4ubuntu3.1 => 245.4-4ubuntu3.2)
   udev (245.4-4ubuntu3.1 => 245.4-4ubuntu3.2)
   ...
17 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

root@foo:~# reboot

Verifying the bug is fixed:

root@foo:~# systemctl status test.service
● test.service - Test Truncate
 Loaded: loaded (/etc/systemd/system/test.service; enabled; vendor preset: 
enabled)
 Active: active (exited) since Mon 2020-07-20 18:12:09 UTC; 1s ago
Process: 139 ExecStart=/usr/lib/test.sh long-test-for-start (code=exited, 
status=0/SUCCESS)
   Main PID: 139 (code=exited, status=0/SUCCESS)

Jul 20 18:12:09 foo systemd[1]: Starting Test Truncate...
Jul 20 18:12:09 foo test.sh[140]: This will
Jul 20 18:12:09 foo test.sh[141]: usually fail
Jul 20 18:12:09 foo test.sh[142]: and be truncated
Jul 20 18:12:09 foo systemd[1]: Finished Test Truncate.


It is so marking as such, thanks!

** Tags removed: verification-needed verification-needed-focal
** Tags added: verification-done verification-done-focal

-- 
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/1875708

Title:
  Truncated messages in journald since systemd v244

Status in libvirt package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Released
Status in libvirt source package in Focal:
  Confirmed
Status in systemd source package in Focal:
  Fix Committed
Status in libvirt source package in Groovy:
  Invalid
Status in systemd source package in Groovy:
  Fix Released

Bug description:
  [Impact]

   * since 09d0b46a "journal: refresh cached credentials of stdout streams"
 in ~244 output may be trincated.

   * Upstream has a fix in https://github.com/systemd/systemd/pull/15685

   * Backporting the fix will avoid truncation of log output to journald

  [Test Case]

   * This could happen in any case, but is more likely when a program that 
 has output going to journald is spawning short-lived sub-programs often.
 Therefore the test emphasizes on that:

 - Use a test service like /etc/systemd/system/test.service:
  [Unit]
  Description=Test Truncate
  After=network.target

  [Service]
  ExecStart=/usr/lib/test.sh long-test-for-start
  ExecStop=/usr/lib/test.sh long-test-for-stop
  Type=oneshot
  RemainAfterExit=yes
  StandardOutput=journal+console
  TimeoutStopSec=0

  [Install]
  WantedBy=multi-user.target

 - And a test script like /usr/lib/test.sh:
  #!/bin/sh
  gettext "This will"
  echo
  gettext "usually fail"
  echo
  gettext "and be truncated"
  echo 

  Start/Stopping that service without the fix will look like:
  Apr 30 18:56:40 f systemd[1]: Stopping Test Truncate...
  Apr 30 18:56:40 f test.sh[1165]: T
  Apr 30 18:56:40 f test.sh[1167]: T
  Apr 30 18:56:40 f test.sh[1167]: sually fai
  Apr 30 18:56:40 f test.sh[1165]: s
  Apr 30 18:56:40 f test.sh[1168]: s
  Apr 30 18:56:40 f test.sh[1168]: nd be truncate
  Apr 30 18:56:40 f test.sh[1165]: n
  Apr 30 18:56:40 f systemd[1]: test.service: Succeeded.
  Apr 30 18:56:40 f systemd[1]: Stopped Test Truncate.

  
  [Regression Potential] 

   * The patches are rather small, but there might be a slightly increased 
 memory consumption of journald for output buffers. 
   * Issues (if any and I couldn't find any so far) should be only 

[Touch-packages] [Bug 1875708] Re: Truncated messages in journald since systemd v244

2020-06-26 Thread Simon Déziel
A SRU to Focal would be greatly appreciated as dehydrated (Let's Encrypt
client) is also affected, probably because it's in essence just a bash
script. Here are the logs where it seems to indicate the certificate
doesn't need to to be renewed just yet:

Jun 25 00:26:10 rproxy dehydrated[21256]:  + Valid till Aug  4 03:20:48 2020 GMT
Jun 25 00:26:10 rproxy dehydrated[21407]:  + Valid till Aug  4 03:20:4
Jun 25 00:26:10 rproxy dehydrated[21256]:  + Valid till Aug  4 03:20:4
Jun 25 00:26:10 rproxy dehydrated[21256]: Longer tha

Having the full output would be nice :) Count on me for a focal-proposed
verification if you agree on a SRU ;)

-- 
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/1875708

Title:
  Truncated messages in journald since systemd v244

Status in libvirt package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Released
Status in libvirt source package in Focal:
  Confirmed
Status in systemd source package in Focal:
  In Progress
Status in libvirt source package in Groovy:
  Invalid
Status in systemd source package in Groovy:
  Fix Released

Bug description:
  [Impact]

   * since 09d0b46a "journal: refresh cached credentials of stdout streams"
 in ~244 output may be trincated.

   * Upstream has a fix in https://github.com/systemd/systemd/pull/15685

   * Backporting the fix will avoid truncation of log output to journald

  [Test Case]

   * This could happen in any case, but is more likely when a program that 
 has output going to journald is spawning short-lived sub-programs often.
 Therefore the test emphasizes on that:

 - Use a test service like /etc/systemd/system/test.service:
  [Unit]
  Description=Test Truncate
  After=network.target

  [Service]
  ExecStart=/usr/lib/test.sh long-test-for-start
  ExecStop=/usr/lib/test.sh long-test-for-stop
  Type=oneshot
  RemainAfterExit=yes
  StandardOutput=journal+console
  TimeoutStopSec=0

  [Install]
  WantedBy=multi-user.target

 - And a test script like /usr/lib/test.sh:
  #!/bin/sh
  gettext "This will"
  echo
  gettext "usually fail"
  echo
  gettext "and be truncated"
  echo 

  Start/Stopping that service without the fix will look like:
  Apr 30 18:56:40 f systemd[1]: Stopping Test Truncate...
  Apr 30 18:56:40 f test.sh[1165]: T
  Apr 30 18:56:40 f test.sh[1167]: T
  Apr 30 18:56:40 f test.sh[1167]: sually fai
  Apr 30 18:56:40 f test.sh[1165]: s
  Apr 30 18:56:40 f test.sh[1168]: s
  Apr 30 18:56:40 f test.sh[1168]: nd be truncate
  Apr 30 18:56:40 f test.sh[1165]: n
  Apr 30 18:56:40 f systemd[1]: test.service: Succeeded.
  Apr 30 18:56:40 f systemd[1]: Stopped Test Truncate.

  
  [Regression Potential] 

   * The patches are rather small, but there might be a slightly increased 
 memory consumption of journald for output buffers. 
   * Issues (if any and I couldn't find any so far) should be only to 
 journald output handling. Systemd is huge, this at least narrows
 down the potential places of a regression a lot.

  [Other Info]
   
   * n/a

  --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---

  Originally reported against libvirt which happens to be one of the
  example-triggers

  Hi,

  when I shut down my machine I see messages from /usr/lib/libvirt
  /libvirt-guests.sh but there are 2 anomalies:

   - 3 libvirt-guests.sh processes are run
   - messages are truncated

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: libvirt-daemon 6.0.0-0ubuntu8
  Uname: Linux 5.6.7-050607-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: KDE
  Date: Tue Apr 28 19:42:56 2020
  SourcePackage: libvirt
  UpgradeStatus: No upgrade log present (probably fresh install)
  modified.conffile..etc.libvirt.nwfilter.allow-arp.xml: [inaccessible: [Errno 
13] Permission denied: '/etc/libvirt/nwfilter/allow-arp.xml']
  modified.conffile..etc.libvirt.nwfilter.allow-dhcp-server.xml: [inaccessible: 
[Errno 13] Permission denied: '/etc/libvirt/nwfilter/allow-dhcp-server.xml']
  modified.conffile..etc.libvirt.nwfilter.allow-dhcp.xml: [inaccessible: [Errno 
13] Permission denied: '/etc/libvirt/nwfilter/allow-dhcp.xml']
  modified.conffile..etc.libvirt.nwfilter.allow-incoming-ipv4.xml: 
[inaccessible: [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/allow-incoming-ipv4.xml']
  modified.conffile..etc.libvirt.nwfilter.allow-ipv4.xml: [inaccessible: [Errno 
13] Permission denied: '/etc/libvirt/nwfilter/allow-ipv4.xml']
  modified.conffile..etc.libvirt.nwfilter.clean-traffic-gateway.xml: 
[inaccessible: [Errno 13] Permission denied: 
'/etc/libvirt/nwfilter/clean-traffic-gateway.xml']
  modified.conffile..etc.libvirt.nwfilter.clean-traffic.xml: [inaccessible: 
[Errno 13] Permission denied: '/etc/libvirt/nwfilter/clean-traffic.xml']
  modified.conffile..etc.libvirt.nwfilter.no-arp-ip-spoofing.xml: 

[Touch-packages] [Bug 1827253] Re: [apparmor] missing 'mr' on binary for usage on containers

2020-06-25 Thread Simon Déziel
@Christian,
https://code.launchpad.net/~sdeziel/ubuntu/+source/rsyslog/+git/rsyslog/+merge/382345
was a 'drive-by' merge proposal not associated with any LP (is that
OK?). As such, I don't consider it related to this bug which can be
closed now AFAICT.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1827253

Title:
  [apparmor] missing 'mr' on binary for usage on containers

Status in rsyslog package in Ubuntu:
  Fix Released
Status in rsyslog source package in Bionic:
  In Progress
Status in rsyslog source package in Disco:
  In Progress
Status in rsyslog source package in Eoan:
  In Progress

Bug description:
  [Impact]

   * rsyslog ships with a (Default disable) apparmor profile.
   * Security sensitive users are in general encouraged to enable such
     profiles but unfortunately due to slightly new behavior of the program
     the profile prevents its usage.
   * Allow the program to map/read its binary to get this working again

  [Test Case]

  1) Create a 'eoan' container called rs1 here:
    lxc launch ubuntu-daily:e rs1
  2) Enter the container
    lxc shell rs1
  3) Enable apparmor profile
    rm /etc/apparmor.d/disable/usr.sbin.rsyslogd
    apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
    systemctl restart rsyslog
  4) notice rsyslog failed to start
    systemctl status rsyslog

  [Regression Potential]

   * This is just opening up the apparmor profile a bit. Therefore the only
     regression it could cause IMHO is a security issue. But then what it
     actually allows is reading (not writing!) its own binary which should
     be very safe.
   * Thinking further it came to my mind that package updates (independent 
 to the change) might restart services and that means if there is any 
 issue e.g. in a local config that worked but now fails (not by this 
 change but in general) then the upgrade will not cause, but trigger 
 this. This is a general regression risk for any upload, but in this 
 case worth to mention as it is about log handling - which if broken - 
 makes large scale systems hard to debug.

  [Other Info]

   * n/a

  ---

  Issue description:

  Enabling the rsyslog (disabled by default) Apparmor profile causes
  rsyslog to fail to start when running *inside a container*.

  Steps to reproduce:

  1) Create a 'eoan' container called rs1 here:
    lxc launch ubuntu-daily:e rs1
  2) Enter the container
    lxc shell rs1
  3) Enable apparmor profile
    rm /etc/apparmor.d/disable/usr.sbin.rsyslogd
    apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
    systemctl restart rsyslog
  4) notice rsyslog failed to start
    systemctl status rsyslog

  Workaround:

    echo '  /usr/sbin/rsyslogd mr,' >> /etc/apparmor.d/local/usr.sbin.rsyslogd
    apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
    systemctl restart rsyslog

  Additional information:

  root@rs1:~# uname -a
  Linux rs1 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 
x86_64 x86_64 GNU/Linux
  root@rs1:~# lsb_release -rd
  Description:  Ubuntu Eoan EANIMAL (development branch)
  Release:  19.10
  root@rs1:~# dpkg -l| grep -wE 'apparmor|rsyslog'
  ii  apparmor 2.13.2-9ubuntu6  amd64user-space parser utility for 
AppArmor
  ii  rsyslog  8.32.0-1ubuntu7  amd64reliable system and kernel logging 
daemon

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: rsyslog 8.32.0-1ubuntu7
  ProcVersionSignature: Ubuntu 4.15.0-48.51-generic 4.15.18
  Uname: Linux 4.15.0-48-generic x86_64
  ApportVersion: 2.20.10-0ubuntu27
  Architecture: amd64
  Date: Wed May  1 17:36:29 2019
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: rsyslog
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1827253/+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


Re: [Touch-packages] [Bug 1872564] Re: /proc/sys/kernel/random/boot_id rule missing from abstractions/nameservice

2020-06-03 Thread Simon Déziel
On 2020-06-02 8:50 p.m., Chris Halse Rogers wrote:
> You don't *have* to include the full output of the test cases when
> verifying a bug (although, depending on how much output there is, it can
> be nice).

OK, good, thanks for clarifying!

> I don't think it was clear that you *had* gone through the full test-
> case in your verification comment - I'm not entirely sure what gave that
> impression, but I think it might have been the combination of *some*
> output (the apt/dpkg bit) and saying “the bug is fixed, thanks” without
> making reference to the test case.

True, I should have been more explicit, duly noted!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1872564

Title:
  /proc/sys/kernel/random/boot_id rule missing from
  abstractions/nameservice

Status in apparmor package in Ubuntu:
  Fix Released
Status in apparmor source package in Focal:
  Fix Released

Bug description:
  [Impact]

  On a default Focal install, systemd is used when looking up passwd and
  group information:

  # grep systemd /etc/nsswitch.conf
  passwd: files systemd
  group:  files systemd

  Daemons confined by Apparmor that also query those "databases" will
  cause this Apparmor denial:

  audit: type=1400 audit(1586825456.411:247): apparmor="DENIED"
  operation="open" namespace="root//lxd-fb1_"
  profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id"
  pid=7370 comm="named" requested_mask="r" denied_mask="r" fsuid=100
  ouid=100

  Many daemons confined by Apparmor also happen to downgrade their
  privileges so they always end up looking up user/group information.

  To fix this problem, we had to backport an upstream patch which adds
  new directives to the 'nameservices' apparmor profile.

  [Test Case]

  In order to reproduce the bug, one can:

  1) launch a Focal container (named fb1 here)
  $ lxc launch images:ubuntu/focal fb1

  2) setup apparmor inside the container (already done on official Ubuntu 
images)
  $ lxc exec fb1 -- apt update && lxc exec fb1 -- apt install apparmor -y

  3) install bind9
  $ lxc exec fb1 -- apt install bind9 -y

  4) check kernel logs for DENIED
  $ journalctl -o cat -b0 -k | grep 'apparmor="DENIED"' | grep -F 
'profile="/usr/sbin/named"'

  or, depending on how logging is configured:

  $ dmesg | grep 'apparmor="DENIED"' | grep -F
  'profile="/usr/sbin/named"'

  Step 4, should not return anything. Because systemd is involved in the
  user/group lookups, it currently returns the following:

  audit: type=1400 audit(1586826072.115:266): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:267): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:268): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:269): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:270): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100

  [Regression Potential]

  In order to fix this issue, 3 separate patches had to be backported.
  They are simple and self-contained, especially two of them, whose
  purposes are to add the definition of the @{run} variable and then to
  add a trailing slash at the end of the "/run" pathname.

  The other patch, albeit very simple, adds three statements to the
  'nameservice' profile in order to let processes access (read-only)
  files under "/run/systemd/userdb" and
  "/proc/sys/kernel/random/boot_id".  After thinking about the possible
  cases, the only possible problem I could envision was for a program
  that, not being able to access some of these files before, will now be
  able to do that and therefore exercise a part of its codebase which
  was not being used, possibly uncovering latent bugs in this software.
  But this is not a regression of apparmor per se.

  [Original Description]

  (Description and Test Case were moved above)

  # Workaround

  1) remove systemd from nsswitch.conf
  $ lxc exec fb1 -- sed -i 's/ systemd$/ # systemd/' 

[Touch-packages] [Bug 1872564] Re: /proc/sys/kernel/random/boot_id rule missing from abstractions/nameservice

2020-06-02 Thread Simon Déziel
@Brian, I did go through the full test case when marking it as verified
in comment #20.

Do I really need to repeat the full test case when verifying a bug?

$ lxc launch images:ubuntu/focal fb1
$ lxc exec fb1 -- apt update && lxc exec fb1 -- apt install apparmor -y
$ lxc exec fb1 -- apt install bind9 -y

# Confirms the problem:
$ journalctl -o cat -b0 -k | grep 'apparmor="DENIED"' | grep -F 
'profile="/usr/sbin/named"'
audit: type=1400 audit(1591130868.387:930): apparmor="DENIED" operation="open" 
namespace="root//lxd-fb1_" profile="/usr/sbin/named" 
name="/proc/sys/kernel/random/boot_id" pid=21656 comm="named" 
requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1591130868.387:931): apparmor="DENIED" operation="open" 
namespace="root//lxd-fb1_" profile="/usr/sbin/named" 
name="/proc/sys/kernel/random/boot_id" pid=21656 comm="named" 
requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1591130868.387:932): apparmor="DENIED" operation="open" 
namespace="root//lxd-fb1_" profile="/usr/sbin/named" 
name="/proc/sys/kernel/random/boot_id" pid=21656 comm="named" 
requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1591130868.387:933): apparmor="DENIED" operation="open" 
namespace="root//lxd-fb1_" profile="/usr/sbin/named" 
name="/proc/sys/kernel/random/boot_id" pid=21656 comm="named" 
requested_mask="r" denied_mask="r" fsuid=100 ouid=100

Bringing in the fix from -proposed:

$ echo 'deb http://archive.ubuntu.com/ubuntu focal-proposed main' | lxc exec 
fb1 -- tee /etc/apt/sources.list
$ lxc exec fb1 -- apt update
$ lxc exec fb1 -- apt install apparmor
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Suggested packages:
  apparmor-profiles-extra apparmor-utils
The following packages will be upgraded:
  apparmor
1 upgraded, 0 newly installed, 0 to remove and 8 not upgraded.
Need to get 494 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 apparmor amd64 
2.13.3-7ubuntu5.1 [494 kB]
Fetched 494 kB in 1s (929 kB/s) 
Preconfiguring packages ...
(Reading database ... 14968 files and directories currently installed.)
Preparing to unpack .../apparmor_2.13.3-7ubuntu5.1_amd64.deb ...
Unpacking apparmor (2.13.3-7ubuntu5.1) over (2.13.3-7ubuntu5) ...
Setting up apparmor (2.13.3-7ubuntu5.1) ...
Installing new version of config file /etc/apparmor.d/abstractions/nameservice 
...
Reloading AppArmor profiles 
Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd
Processing triggers for systemd (245.4-4ubuntu3.1) ...
$ lxc exec fb1 -- systemctl restart named

No *new* DENIED messages in 'journalctl -k', so marking as verification-
done.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1872564

Title:
  /proc/sys/kernel/random/boot_id rule missing from
  abstractions/nameservice

Status in apparmor package in Ubuntu:
  Fix Released
Status in apparmor source package in Focal:
  Fix Committed

Bug description:
  [Impact]

  On a default Focal install, systemd is used when looking up passwd and
  group information:

  # grep systemd /etc/nsswitch.conf
  passwd: files systemd
  group:  files systemd

  Daemons confined by Apparmor that also query those "databases" will
  cause this Apparmor denial:

  audit: type=1400 audit(1586825456.411:247): apparmor="DENIED"
  operation="open" namespace="root//lxd-fb1_"
  profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id"
  pid=7370 comm="named" requested_mask="r" denied_mask="r" fsuid=100
  ouid=100

  Many daemons confined by Apparmor also happen to downgrade their
  privileges so they always end up looking up user/group information.

  To fix this problem, we had to backport an upstream patch which adds
  new directives to the 'nameservices' apparmor profile.

  [Test Case]

  In order to reproduce the bug, one can:

  1) launch a Focal container (named fb1 here)
  $ lxc launch images:ubuntu/focal fb1

  2) setup apparmor inside the container (already done on official Ubuntu 
images)
  $ lxc exec fb1 -- apt update && lxc exec fb1 -- apt install apparmor -y

  3) install bind9
  $ lxc exec fb1 -- apt install bind9 -y

  4) check kernel logs for DENIED
  $ journalctl -o cat -b0 -k | grep 'apparmor="DENIED"' | grep -F 
'profile="/usr/sbin/named"'

  or, depending on how logging is configured:

  $ dmesg | grep 'apparmor="DENIED"' | grep -F
  'profile="/usr/sbin/named"'

  Step 4, should not return anything. Because systemd is involved in the
  user/group lookups, it currently returns the following:

  audit: type=1400 audit(1586826072.115:266): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 

[Touch-packages] [Bug 1872564] Re: /proc/sys/kernel/random/boot_id rule missing from abstractions/nameservice

2020-06-02 Thread Simon Déziel
** Tags removed: verification-needed verification-needed-focal
** Tags added: verification-done verification-done-focal

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1872564

Title:
  /proc/sys/kernel/random/boot_id rule missing from
  abstractions/nameservice

Status in apparmor package in Ubuntu:
  Fix Released
Status in apparmor source package in Focal:
  Fix Committed

Bug description:
  [Impact]

  On a default Focal install, systemd is used when looking up passwd and
  group information:

  # grep systemd /etc/nsswitch.conf
  passwd: files systemd
  group:  files systemd

  Daemons confined by Apparmor that also query those "databases" will
  cause this Apparmor denial:

  audit: type=1400 audit(1586825456.411:247): apparmor="DENIED"
  operation="open" namespace="root//lxd-fb1_"
  profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id"
  pid=7370 comm="named" requested_mask="r" denied_mask="r" fsuid=100
  ouid=100

  Many daemons confined by Apparmor also happen to downgrade their
  privileges so they always end up looking up user/group information.

  To fix this problem, we had to backport an upstream patch which adds
  new directives to the 'nameservices' apparmor profile.

  [Test Case]

  In order to reproduce the bug, one can:

  1) launch a Focal container (named fb1 here)
  $ lxc launch images:ubuntu/focal fb1

  2) setup apparmor inside the container (already done on official Ubuntu 
images)
  $ lxc exec fb1 -- apt update && lxc exec fb1 -- apt install apparmor -y

  3) install bind9
  $ lxc exec fb1 -- apt install bind9 -y

  4) check kernel logs for DENIED
  $ journalctl -o cat -b0 -k | grep 'apparmor="DENIED"' | grep -F 
'profile="/usr/sbin/named"'

  or, depending on how logging is configured:

  $ dmesg | grep 'apparmor="DENIED"' | grep -F
  'profile="/usr/sbin/named"'

  Step 4, should not return anything. Because systemd is involved in the
  user/group lookups, it currently returns the following:

  audit: type=1400 audit(1586826072.115:266): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:267): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:268): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:269): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:270): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100

  [Regression Potential]

  In order to fix this issue, 3 separate patches had to be backported.
  They are simple and self-contained, especially two of them, whose
  purposes are to add the definition of the @{run} variable and then to
  add a trailing slash at the end of the "/run" pathname.

  The other patch, albeit very simple, adds three statements to the
  'nameservice' profile in order to let processes access (read-only)
  files under "/run/systemd/userdb" and
  "/proc/sys/kernel/random/boot_id".  After thinking about the possible
  cases, the only possible problem I could envision was for a program
  that, not being able to access some of these files before, will now be
  able to do that and therefore exercise a part of its codebase which
  was not being used, possibly uncovering latent bugs in this software.
  But this is not a regression of apparmor per se.

  [Original Description]

  (Description and Test Case were moved above)

  # Workaround

  1) remove systemd from nsswitch.conf
  $ lxc exec fb1 -- sed -i 's/ systemd$/ # systemd/' /etc/nsswitch.conf
  2) restart named
  $ lxc exec fb1 -- service named restart
  3) notice no more denials in kernel logs

  # Additional information

  root@fb1:~# apt-cache policy apparmor
  apparmor:
    Installed: 2.13.3-7ubuntu4
    Candidate: 2.13.3-7ubuntu4
    Version table:
   *** 2.13.3-7ubuntu4 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status

  root@fb1:~# uname -a
  Linux fb1 5.3.0-46-generic #38~18.04.1-Ubuntu SMP Tue Mar 31 04:17:56 

Re: [Touch-packages] [Bug 1877159] Re: netlink: 'systemd-network': attribute type 5 has an invalid length.

2020-05-25 Thread Simon Déziel
On 2020-05-25 4:17 a.m., Łukasz Zemczak wrote:
> This is fine right now, but please be sure to be a bit more verbose
> about what kind of testing has been performed on the selected package!

I went through the [test case] steps before and after the -proposed
update. Should I simply explicitly mention me going trough it or do I
need to copy it again?

-- 
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/1877159

Title:
  netlink: 'systemd-network': attribute type 5 has an invalid length.

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in systemd source package in Eoan:
  Fix Released
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [impact]

  systemd-networkd uses incorrect netlink attribute length for
  wireguard's persistent keepalive interval, which logs error messages
  from the kernel, and may incorrectly set the parameter.

  [test case]

  Only 1 Bionic VM is required to reproduce the problem:

  $ lxc launch images:ubuntu/bionic --vm -c security.secureboot=false foo
  $ sleep 10 # allow booting
  $ lxc exec foo -- apt install -y software-properties-common
  $ lxc exec foo -- add-apt-repository -y ppa:wireguard/wireguard
  $ lxc exec foo -- apt install -y wireguard-tools

  $ cat << EOF | lxc exec foo -- tee /etc/systemd/network/wg0.netdev
  # foo
  [NetDev]
  Name=wg0
  Kind=wireguard

  [WireGuard]
  ListenPort=
  PrivateKey=cBkljQSKhtEe/U8GZmCAk2MBbKWL4TLC9PVtbMFyCVQ=

  [WireGuardPeer]
  PublicKey=emfIuZ3hZ+AnWIrKex/EqCp2mfzip8AxJu6RuweyRGc=
  AllowedIPs=192.168.255.2
  Endpoint=bar.lxd:
  EOF

  $ cat << EOF | lxc exec foo -- tee /etc/systemd/network/wg0.network
  # foo
  [Match]
  Name=wg0

  [Network]
  Address=192.168.255.1/24
  EOF

  $ lxc exec foo -- systemctl restart systemd-networkd

  # notice the invalid length in dmesg
  $ lxc exec foo -- journalctl -kn 8
  -- Logs begin at Mon 2020-05-11 16:56:40 UTC, end at Mon 2020-05-11 17:03:46 
UTC. --
  May 11 16:58:25 foo kernel: nf_tables: (c) 2007-2009 Patrick McHardy 

  May 11 17:01:57 foo kernel: PKCS#7 signature not signed with a trusted key
  May 11 17:01:57 foo kernel: wireguard: module verification failed: signature 
and/or required key missing - tainting kernel
  May 11 17:01:57 foo kernel: wireguard: WireGuard 1.0.20200429 loaded. See 
www.wireguard.com for information.
  May 11 17:01:57 foo kernel: wireguard: Copyright (C) 2015-2019 Jason A. 
Donenfeld . All Rights Reserved.
  May 11 17:01:57 foo kernel: netlink: 'systemd-network': attribute type 5 has 
an invalid length.
  May 11 17:01:57 foo kernel: netlink: 'systemd-network': attribute type 5 has 
an invalid length.
  May 11 17:02:23 foo kernel: netlink: 'systemd-network': attribute type 5 has 
an invalid length.

  [regression potential]

  this adjusts the length of the specific netlink parameter, so any
  regression would likely relate to incorrectly setting the persistent
  keepalive interval parameter, or failure to set the parameter.

  [scope]

  this is needed only for Bionic.

  this was fixed upstream in commit
  7d0b26a027118ca063780421cb31c74e9d2664ee which was first included in
  v240, so this is fixed in Eoan and later.  Xenial does not include
  support for wireguard, so this does not apply there.

  [original description]

  This morning, our 2 Bionic machine configured with the wireguard's PPA
  and using systemd-networkd to configure the wireguard tunnel started
  misbehaving. Why this started just now is unclear ATM but their dmesg
  was filled with this:

  validate_nla: 100 callbacks suppressed
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.

  Folks in #systemd mentioned
  https://github.com/systemd/systemd/issues/11575 which points to 2
  commits missing from Bionic's systemd version:

  
https://github.com/systemd/systemd/commit/7d0b26a027118ca063780421cb31c74e9d2664ee
  
https://github.com/systemd/systemd/commit/624a47694cad4c87b2e807c32db656f3e9d679c5

  Focal's systemd have the above commits. Would it be possible to
  backport those 2 commits to Bionic?

  Additional information:

  # uname -a
  Linux noc-eu1 4.15.0-99-generic #100-Ubuntu SMP Wed Apr 22 20:32:56 UTC 2020 
x86_64 x86_64 

[Touch-packages] [Bug 1860926] Re: Ubuntu 20.04 Systemd fails to configure bridged network

2020-05-24 Thread Simon Déziel
On Focal, I can confirm the bug and the fix from 245.4-4ubuntu3.1
(focal-proposed). Thanks for working on this!

-- 
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/1860926

Title:
  Ubuntu 20.04  Systemd fails to configure bridged network

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Eoan:
  Fix Committed
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Released

Bug description:
  [impact]

  A bridged interface with static ipv4 address and gateway configuration
  will fail to properly add the route via the gateway, leaving the
  system without a globally working network.

  [test case]

  On a Focal system, remove all network configuration and create this
  netplan:

  network:
    version: 2
    renderer: networkd
    ethernets:
  enp4s0:
    dhcp4: false
    bridges:
  br0:
    interfaces: [enp4s0]
    dhcp4: no
    addresses: [192.168.0.4/24]
    gateway4: 192.168.0.1
    nameservers:
  search: [mydomain]
  addresses: [192.168.0.1,192.168.0.2,192.168.0.3]

  Replace the interface name 'enp4s0' with the actual interface name on
  the test system.

  Reboot the system, and check the route to the gateway, which will be
  missing:

  root@lp1860926-f:~# ip r
  192.168.0.0/24 dev br0 proto kernel scope link src 192.168.0.4

  The route is expected to be present, e.g.:

  ubuntu@lp1860926-e:~$ ip r
  default via 192.168.0.1 dev br0 proto static
  192.168.0.0/24 dev br0 proto kernel scope link src 192.168.0.4

  [test case, pre-focal]

  same netplan as above, but remove ethernets: section.  Reboot, and the
  bridge should have its address and route:

  ubuntu@test-e:~$ ip a show br0
  3: br0:  mtu 1500 qdisc noqueue state DOWN 
group default qlen 1000
  link/ether 56:11:da:23:bb:93 brd ff:ff:ff:ff:ff:ff
  inet 192.168.0.4/24 brd 192.168.0.255 scope global br0
 valid_lft forever preferred_lft forever
  ubuntu@test-e:~$ ip r
  default via 192.168.0.1 dev br0 proto static linkdown 
  192.168.0.0/24 dev br0 proto kernel scope link src 192.168.0.4 linkdown 

  
  add and remove carrier, by adding and removing a slave interface:

  ubuntu@test-e:~$ sudo ip l set dev ens3 master br0 up
  ubuntu@test-e:~$ ip a show br0
  3: br0:  mtu 1500 qdisc noqueue state UP 
group default qlen 1000
  link/ether 56:11:da:23:bb:93 brd ff:ff:ff:ff:ff:ff
  inet 192.168.0.4/24 brd 192.168.0.255 scope global br0
 valid_lft forever preferred_lft forever
  inet6 fe80::5411:daff:fe23:bb93/64 scope link 
 valid_lft forever preferred_lft forever
  ubuntu@test-e:~$ sudo ip l set dev ens3 nomaster

  
  the bridge no longer has its address after losing carrier:

  ubuntu@test-e:~$ ip a show br0
  3: br0:  mtu 1500 qdisc noqueue state DOWN 
group default qlen 1000
  link/ether 56:11:da:23:bb:93 brd ff:ff:ff:ff:ff:ff
  inet6 fe80::5411:daff:fe23:bb93/64 scope link 
 valid_lft forever preferred_lft forever


  [regression potential]

  Any regression would likely involve incorrectly configured network
  after an interface carrier gain/loss.

  [scope]

  This is needed for Focal, Eoan, and Bionic.

  While this only reproduces at boot for Focal, the general loss of
  configuration on carrier loss even when ConfigureWithoutCarrier=true
  is reproducable on all releases except Xenial, which does not have the
  ConfigureWithoutCarrier= parameter.

  [original description]

  Freshly installed Ubuntu 20.04 fully patched to days date with static
  IP address works fine and survives a reboot

  network:
    version: 2
    renderer: networkd
    ethernets:
  enp4s0:
    dhcp4: false
    addresses: [192.168.0.4/24]
    gateway4: 192.168.0.1
    nameservers:
  search: [mydomain]
  addresses: [192.168.0.1,192.168.0.2,192.168.0.3]

  however when converted to a bridged network for kvm

  network:
    version: 2
    renderer: networkd
    ethernets:
  enp4s0:
    dhcp4: false
    bridges:
  br0:
    interfaces: [enp4s0]
    dhcp4: no
    addresses: [192.168.0.4/24]
    gateway4: 192.168.0.1
    nameservers:
  search: [mydomain]
  addresses: [192.168.0.1,192.168.0.2,192.168.0.3]

  will not survive a reboot and required systemd-network to be restarted or
  @reboot /usr/sbin/netplan apply
  added to the crontab

  after a reboot the network can not b eaccseed and a
  systemctl status systemd-networkd produces

  systemd-networkd.service - Network Service
   Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; 
vendor preset: enabled)
   Active: active (running) since Sun 2020-01-26 16:36:28 UTC; 2min 27s ago
  TriggeredBy: ● systemd-networkd.socket
     Docs: 

[Touch-packages] [Bug 1872564] Re: /proc/sys/kernel/random/boot_id rule missing from abstractions/nameservice

2020-05-22 Thread Simon Déziel
After pulling apparmor 2.13.3-7ubuntu5.1 from focal-proposed:

Get:18 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 apparmor 
amd64 2.13.3-7ubuntu5.1 [494 kB]
...
Unpacking apparmor (2.13.3-7ubuntu5.1) over (2.13.3-7ubuntu5) ...
Setting up libapparmor1:amd64 (2.13.3-7ubuntu5.1) ...
Setting up apt-utils (2.0.3) ...
Setting up apparmor (2.13.3-7ubuntu5.1) ...
Installing new version of config file /etc/apparmor.d/abstractions/nameservice 
...
Reloading AppArmor profiles 
Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd
...

I'm happy to report the bug is fixed, thanks so much!

** Tags removed: verification-needed verification-needed-focal
** Tags added: verification-done verification-done-focal

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1872564

Title:
  /proc/sys/kernel/random/boot_id rule missing from
  abstractions/nameservice

Status in apparmor package in Ubuntu:
  Fix Released
Status in apparmor source package in Focal:
  Fix Committed

Bug description:
  [Impact]

  On a default Focal install, systemd is used when looking up passwd and
  group information:

  # grep systemd /etc/nsswitch.conf
  passwd: files systemd
  group:  files systemd

  Daemons confined by Apparmor that also query those "databases" will
  cause this Apparmor denial:

  audit: type=1400 audit(1586825456.411:247): apparmor="DENIED"
  operation="open" namespace="root//lxd-fb1_"
  profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id"
  pid=7370 comm="named" requested_mask="r" denied_mask="r" fsuid=100
  ouid=100

  Many daemons confined by Apparmor also happen to downgrade their
  privileges so they always end up looking up user/group information.

  To fix this problem, we had to backport an upstream patch which adds
  new directives to the 'nameservices' apparmor profile.

  [Test Case]

  In order to reproduce the bug, one can:

  1) launch a Focal container (named fb1 here)
  $ lxc launch images:ubuntu/focal fb1

  2) setup apparmor inside the container (already done on official Ubuntu 
images)
  $ lxc exec fb1 -- apt update && lxc exec fb1 -- apt install apparmor -y

  3) install bind9
  $ lxc exec fb1 -- apt install bind9 -y

  4) check kernel logs for DENIED
  $ journalctl -o cat -b0 -k | grep 'apparmor="DENIED"' | grep -F 
'profile="/usr/sbin/named"'

  or, depending on how logging is configured:

  $ dmesg | grep 'apparmor="DENIED"' | grep -F
  'profile="/usr/sbin/named"'

  Step 4, should not return anything. Because systemd is involved in the
  user/group lookups, it currently returns the following:

  audit: type=1400 audit(1586826072.115:266): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:267): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:268): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:269): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:270): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100

  [Regression Potential]

  In order to fix this issue, 3 separate patches had to be backported.
  They are simple and self-contained, especially two of them, whose
  purposes are to add the definition of the @{run} variable and then to
  add a trailing slash at the end of the "/run" pathname.

  The other patch, albeit very simple, adds three statements to the
  'nameservice' profile in order to let processes access (read-only)
  files under "/run/systemd/userdb" and
  "/proc/sys/kernel/random/boot_id".  After thinking about the possible
  cases, the only possible problem I could envision was for a program
  that, not being able to access some of these files before, will now be
  able to do that and therefore exercise a part of its codebase which
  was not being used, possibly uncovering latent bugs in this software.
  But this is not a regression of apparmor per se.

  [Original Description]

  (Description and Test Case were moved above)

  # Workaround

[Touch-packages] [Bug 1872564] Re: /proc/sys/kernel/random/boot_id rule missing from abstractions/nameservice

2020-05-20 Thread Simon Déziel
To save you some work, I'll be happy to do the verification as soon as
something lands in focal-proposed. Thanks

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1872564

Title:
  /proc/sys/kernel/random/boot_id rule missing from
  abstractions/nameservice

Status in apparmor package in Ubuntu:
  Fix Released
Status in apparmor source package in Focal:
  In Progress

Bug description:
  [Impact]

  On a default Focal install, systemd is used when looking up passwd and
  group information:

  # grep systemd /etc/nsswitch.conf
  passwd: files systemd
  group:  files systemd

  Daemons confined by Apparmor that also query those "databases" will
  cause this Apparmor denial:

  audit: type=1400 audit(1586825456.411:247): apparmor="DENIED"
  operation="open" namespace="root//lxd-fb1_"
  profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id"
  pid=7370 comm="named" requested_mask="r" denied_mask="r" fsuid=100
  ouid=100

  Many daemons confined by Apparmor also happen to downgrade their
  privileges so they always end up looking up user/group information.

  To fix this problem, we had to backport an upstream patch which adds
  new directives to the 'nameservices' apparmor profile.

  [Test Case]

  In order to reproduce the bug, one can:

  1) launch a Focal container (named fb1 here)
  $ lxc launch images:ubuntu/focal fb1

  2) setup apparmor inside the container (already done on official Ubuntu 
images)
  $ lxc exec fb1 -- apt update && lxc exec fb1 -- apt install apparmor -y

  3) install bind9
  $ lxc exec fb1 -- apt install bind9 -y

  4) check kernel logs for DENIED
  $ journalctl -o cat -b0 -k | grep 'apparmor="DENIED"' | grep -F 
'profile="/usr/sbin/named"'

  or, depending on how logging is configured:

  $ dmesg | grep 'apparmor="DENIED"' | grep -F
  'profile="/usr/sbin/named"'

  Step 4, should not return anything. Because systemd is involved in the
  user/group lookups, it currently returns the following:

  audit: type=1400 audit(1586826072.115:266): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:267): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:268): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:269): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:270): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100

  [Regression Potential]

  In order to fix this issue, 3 separate patches had to be backported.
  They are simple and self-contained, especially two of them, whose
  purposes are to add the definition of the @{run} variable and then to
  add a trailing slash at the end of the "/run" pathname.

  The other patch, albeit very simple, adds three statements to the
  'nameservice' profile in order to let processes access (read-only)
  files under "/run/systemd/userdb" and
  "/proc/sys/kernel/random/boot_id".  After thinking about the possible
  cases, the only possible problem I could envision was for a program
  that, not being able to access some of these files before, will now be
  able to do that and therefore exercise a part of its codebase which
  was not being used, possibly uncovering latent bugs in this software.
  But this is not a regression of apparmor per se.

  [Original Description]

  (Description and Test Case were moved above)

  # Workaround

  1) remove systemd from nsswitch.conf
  $ lxc exec fb1 -- sed -i 's/ systemd$/ # systemd/' /etc/nsswitch.conf
  2) restart named
  $ lxc exec fb1 -- service named restart
  3) notice no more denials in kernel logs

  # Additional information

  root@fb1:~# apt-cache policy apparmor
  apparmor:
    Installed: 2.13.3-7ubuntu4
    Candidate: 2.13.3-7ubuntu4
    Version table:
   *** 2.13.3-7ubuntu4 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status

  root@fb1:~# uname -a
  Linux fb1 5.3.0-46-generic #38~18.04.1-Ubuntu SMP Tue Mar 31 04:17:56 UTC 

[Touch-packages] [Bug 1877159] Re: netlink: 'systemd-network': attribute type 5 has an invalid length.

2020-05-19 Thread Simon Déziel
It tested fine with 237-3ubuntu10.41:

(Reading database ... 54686 files and directories currently installed.)
Preparing to unpack libnss-systemd_237-3ubuntu10.41_amd64.deb ...
Unpacking libnss-systemd:amd64 (237-3ubuntu10.41) over (237-3ubuntu10.40) ...
Preparing to unpack libpam-systemd_237-3ubuntu10.41_amd64.deb ...
Unpacking libpam-systemd:amd64 (237-3ubuntu10.41) over (237-3ubuntu10.40) ...
Preparing to unpack libsystemd0_237-3ubuntu10.41_amd64.deb ...
Unpacking libsystemd0:amd64 (237-3ubuntu10.41) over (237-3ubuntu10.40) ...
Preparing to unpack libudev1_237-3ubuntu10.41_amd64.deb ...
Unpacking libudev1:amd64 (237-3ubuntu10.41) over (237-3ubuntu10.40) ...
Preparing to unpack systemd_237-3ubuntu10.41_amd64.deb ...
Unpacking systemd (237-3ubuntu10.41) over (237-3ubuntu10.40) ...
Preparing to unpack systemd-sysv_237-3ubuntu10.41_amd64.deb ...
Unpacking systemd-sysv (237-3ubuntu10.41) over (237-3ubuntu10.40) ...
Preparing to unpack udev_237-3ubuntu10.41_amd64.deb ...
Unpacking udev (237-3ubuntu10.41) over (237-3ubuntu10.40) ...
Setting up libsystemd0:amd64 (237-3ubuntu10.41) ...
Setting up libudev1:amd64 (237-3ubuntu10.41) ...
Setting up systemd (237-3ubuntu10.41) ...
Setting up systemd-sysv (237-3ubuntu10.41) ...
Setting up udev (237-3ubuntu10.41) ...


** Tags removed: verification-needed verification-needed-bionic
** Tags added: verification-done verification-done-bionic

-- 
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/1877159

Title:
  netlink: 'systemd-network': attribute type 5 has an invalid length.

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Eoan:
  Fix Released
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [impact]

  systemd-networkd uses incorrect netlink attribute length for
  wireguard's persistent keepalive interval, which logs error messages
  from the kernel, and may incorrectly set the parameter.

  [test case]

  Only 1 Bionic VM is required to reproduce the problem:

  $ lxc launch images:ubuntu/bionic --vm -c security.secureboot=false foo
  $ sleep 10 # allow booting
  $ lxc exec foo -- apt install -y software-properties-common
  $ lxc exec foo -- add-apt-repository -y ppa:wireguard/wireguard
  $ lxc exec foo -- apt install -y wireguard-tools

  $ cat << EOF | lxc exec foo -- tee /etc/systemd/network/wg0.netdev
  # foo
  [NetDev]
  Name=wg0
  Kind=wireguard

  [WireGuard]
  ListenPort=
  PrivateKey=cBkljQSKhtEe/U8GZmCAk2MBbKWL4TLC9PVtbMFyCVQ=

  [WireGuardPeer]
  PublicKey=emfIuZ3hZ+AnWIrKex/EqCp2mfzip8AxJu6RuweyRGc=
  AllowedIPs=192.168.255.2
  Endpoint=bar.lxd:
  EOF

  $ cat << EOF | lxc exec foo -- tee /etc/systemd/network/wg0.network
  # foo
  [Match]
  Name=wg0

  [Network]
  Address=192.168.255.1/24
  EOF

  $ lxc exec foo -- systemctl restart systemd-networkd

  # notice the invalid length in dmesg
  $ lxc exec foo -- journalctl -kn 8
  -- Logs begin at Mon 2020-05-11 16:56:40 UTC, end at Mon 2020-05-11 17:03:46 
UTC. --
  May 11 16:58:25 foo kernel: nf_tables: (c) 2007-2009 Patrick McHardy 

  May 11 17:01:57 foo kernel: PKCS#7 signature not signed with a trusted key
  May 11 17:01:57 foo kernel: wireguard: module verification failed: signature 
and/or required key missing - tainting kernel
  May 11 17:01:57 foo kernel: wireguard: WireGuard 1.0.20200429 loaded. See 
www.wireguard.com for information.
  May 11 17:01:57 foo kernel: wireguard: Copyright (C) 2015-2019 Jason A. 
Donenfeld . All Rights Reserved.
  May 11 17:01:57 foo kernel: netlink: 'systemd-network': attribute type 5 has 
an invalid length.
  May 11 17:01:57 foo kernel: netlink: 'systemd-network': attribute type 5 has 
an invalid length.
  May 11 17:02:23 foo kernel: netlink: 'systemd-network': attribute type 5 has 
an invalid length.

  [regression potential]

  this adjusts the length of the specific netlink parameter, so any
  regression would likely relate to incorrectly setting the persistent
  keepalive interval parameter, or failure to set the parameter.

  [scope]

  this is needed only for Bionic.

  this was fixed upstream in commit
  7d0b26a027118ca063780421cb31c74e9d2664ee which was first included in
  v240, so this is fixed in Eoan and later.  Xenial does not include
  support for wireguard, so this does not apply there.

  [original description]

  This morning, our 2 Bionic machine configured with the wireguard's PPA
  and using systemd-networkd to configure the wireguard tunnel started
  misbehaving. Why this started just now is unclear ATM but their dmesg
  was filled with this:

  validate_nla: 100 callbacks suppressed
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  

[Touch-packages] [Bug 1877159] Re: netlink: 'systemd-network': attribute type 5 has an invalid length.

2020-05-11 Thread Simon Déziel
@ddstreet, PersistentKeepalive is not needed as you'll see in the steps
to reproduce.

** Description changed:

  [impact]
  
  systemd-networkd uses incorrect netlink attribute length for wireguard's
  persistent keepalive interval, which logs error messages from the
  kernel, and may incorrectly set the parameter.
  
  [test case]
  
- TBD
+ Only 1 Bionic VM is required to reproduce the problem:
+ 
+ $ lxc launch images:ubuntu/bionic --vm -c security.secureboot=false foo
+ $ sleep 10 # allow booting
+ $ lxc exec foo -- apt install -y software-properties-common
+ $ lxc exec foo -- add-apt-repository -y ppa:wireguard/wireguard
+ $ lxc exec foo -- apt install -y wireguard-tools
+ 
+ $ cat << EOF | lxc exec foo -- tee /etc/systemd/network/wg0.netdev
+ # foo
+ [NetDev]
+ Name=wg0
+ Kind=wireguard
+ 
+ [WireGuard]
+ ListenPort=
+ PrivateKey=cBkljQSKhtEe/U8GZmCAk2MBbKWL4TLC9PVtbMFyCVQ=
+ 
+ [WireGuardPeer]
+ PublicKey=emfIuZ3hZ+AnWIrKex/EqCp2mfzip8AxJu6RuweyRGc=
+ AllowedIPs=192.168.255.2
+ Endpoint=bar.lxd:
+ EOF
+ 
+ $ cat << EOF | lxc exec foo -- tee /etc/systemd/network/wg0.network
+ # foo
+ [Match]
+ Name=wg0
+ 
+ [Network]
+ Address=192.168.255.1/24
+ EOF
+ 
+ $ lxc exec foo -- systemctl restart systemd-networkd
+ 
+ # notice the invalid length in dmesg
+ $ lxc exec foo -- journalctl -kn 8
+ -- Logs begin at Mon 2020-05-11 16:56:40 UTC, end at Mon 2020-05-11 17:03:46 
UTC. --
+ May 11 16:58:25 foo kernel: nf_tables: (c) 2007-2009 Patrick McHardy 

+ May 11 17:01:57 foo kernel: PKCS#7 signature not signed with a trusted key
+ May 11 17:01:57 foo kernel: wireguard: module verification failed: signature 
and/or required key missing - tainting kernel
+ May 11 17:01:57 foo kernel: wireguard: WireGuard 1.0.20200429 loaded. See 
www.wireguard.com for information.
+ May 11 17:01:57 foo kernel: wireguard: Copyright (C) 2015-2019 Jason A. 
Donenfeld . All Rights Reserved.
+ May 11 17:01:57 foo kernel: netlink: 'systemd-network': attribute type 5 has 
an invalid length.
+ May 11 17:01:57 foo kernel: netlink: 'systemd-network': attribute type 5 has 
an invalid length.
+ May 11 17:02:23 foo kernel: netlink: 'systemd-network': attribute type 5 has 
an invalid length.
  
  [regression potential]
  
  this adjusts the length of the specific netlink parameter, so any
  regression would likely relate to incorrectly setting the persistent
  keepalive interval parameter, or failure to set the parameter.
  
  [scope]
  
  this is needed only for Bionic.
  
  this was fixed upstream in commit
  7d0b26a027118ca063780421cb31c74e9d2664ee which was first included in
  v240, so this is fixed in Eoan and later.  Xenial does not include
  support for wireguard, so this does not apply there.
  
  [original description]
  
  This morning, our 2 Bionic machine configured with the wireguard's PPA
  and using systemd-networkd to configure the wireguard tunnel started
  misbehaving. Why this started just now is unclear ATM but their dmesg
  was filled with this:
  
  validate_nla: 100 callbacks suppressed
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  
  Folks in #systemd mentioned
  https://github.com/systemd/systemd/issues/11575 which points to 2
  commits missing from Bionic's systemd version:
  
  
https://github.com/systemd/systemd/commit/7d0b26a027118ca063780421cb31c74e9d2664ee
  
https://github.com/systemd/systemd/commit/624a47694cad4c87b2e807c32db656f3e9d679c5
  
  Focal's systemd have the above commits. Would it be possible to backport
  those 2 commits to Bionic?
  
  Additional information:
  
  # uname -a
  Linux noc-eu1 4.15.0-99-generic #100-Ubuntu SMP Wed Apr 22 20:32:56 UTC 2020 
x86_64 x86_64 x86_64 GNU/Linux
  
  # apt-cache policy systemd wireguard{,-tools,-dkms}
  systemd:
    Installed: 237-3ubuntu10.39
    Candidate: 237-3ubuntu10.39
    Version table:
   *** 237-3ubuntu10.39 500
  500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   237-3ubuntu10.38 500
  500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 
Packages
   237-3ubuntu10 500
  500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages
  wireguard:
    Installed: 1.0.20200319-1ubuntu1~18.04
    Candidate: 1.0.20200319-1ubuntu1~18.04
    Version table:
   *** 1.0.20200319-1ubuntu1~18.04 500
  

[Touch-packages] [Bug 1877159] Re: netlink: 'systemd-network': attribute type 5 has an invalid length.

2020-05-11 Thread Simon Déziel
Steps to reproduce:

lxc launch images:ubuntu/bionic --vm -c security.secureboot=false foo
sleep 10 # allow booting
lxc exec foo -- apt install -y software-properties-common
lxc exec foo -- add-apt-repository -y ppa:wireguard/wireguard
lxc exec foo -- apt install -y wireguard-tools

cat << EOF | lxc exec foo -- tee /etc/systemd/network/wg0.netdev
# foo
[NetDev]
Name=wg0
Kind=wireguard

[WireGuard]
ListenPort=
PrivateKey=cBkljQSKhtEe/U8GZmCAk2MBbKWL4TLC9PVtbMFyCVQ=

[WireGuardPeer]
PublicKey=emfIuZ3hZ+AnWIrKex/EqCp2mfzip8AxJu6RuweyRGc=
AllowedIPs=192.168.255.2
Endpoint=bar.lxd:
EOF

cat << EOF | lxc exec foo -- tee /etc/systemd/network/wg0.network
# foo
[Match]
Name=wg0

[Network]
Address=192.168.255.1/24
EOF

lxc exec foo -- systemctl restart systemd-networkd


lxc launch images:ubuntu/bionic --vm -c security.secureboot=false bar
sleep 10 # allow booting
lxc exec bar -- apt install -y software-properties-common
lxc exec bar -- add-apt-repository -y ppa:wireguard/wireguard
lxc exec bar -- apt install -y wireguard-tools

cat << EOF | lxc exec bar -- tee /etc/systemd/network/wg0.netdev
# bar
[NetDev]
Name=wg0
Kind=wireguard

[WireGuard]
ListenPort=
PrivateKey=AHNwUJjVO939UYnp+SjrxYDa1ZlU1uIToCF9CHUitXE=

[WireGuardPeer]
PublicKey=7TJBZdnkY8zMRVPACZSxT6xL2pAi7/IL4R1DGeThEhY=
AllowedIPs=192.168.255.1
Endpoint=foo.lxd:
EOF

cat << EOF | lxc exec bar -- tee /etc/systemd/network/wg0.network
# bar
[Match]
Name=wg0

[Network]
Address=192.168.255.2/24
EOF

lxc exec bar -- systemctl restart systemd-networkd

# test connectivity
lxc exec foo -- ping -qc2 192.168.255.2

# notice the invalid length in dmesg
$ lxc exec foo -- journalctl -kn 8
-- Logs begin at Mon 2020-05-11 16:56:40 UTC, end at Mon 2020-05-11 17:03:46 
UTC. --
May 11 16:58:25 foo kernel: nf_tables: (c) 2007-2009 Patrick McHardy 

May 11 17:01:57 foo kernel: PKCS#7 signature not signed with a trusted key
May 11 17:01:57 foo kernel: wireguard: module verification failed: signature 
and/or required key missing - tainting kernel
May 11 17:01:57 foo kernel: wireguard: WireGuard 1.0.20200429 loaded. See 
www.wireguard.com for information.
May 11 17:01:57 foo kernel: wireguard: Copyright (C) 2015-2019 Jason A. 
Donenfeld . All Rights Reserved.
May 11 17:01:57 foo kernel: netlink: 'systemd-network': attribute type 5 has an 
invalid length.
May 11 17:01:57 foo kernel: netlink: 'systemd-network': attribute type 5 has an 
invalid length.
May 11 17:02:23 foo kernel: netlink: 'systemd-network': attribute type 5 has an 
invalid length.

-- 
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/1877159

Title:
  netlink: 'systemd-network': attribute type 5 has an invalid length.

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Eoan:
  Fix Released
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [impact]

  systemd-networkd uses incorrect netlink attribute length for
  wireguard's persistent keepalive interval, which logs error messages
  from the kernel, and may incorrectly set the parameter.

  [test case]

  Only 1 Bionic VM is required to reproduce the problem:

  $ lxc launch images:ubuntu/bionic --vm -c security.secureboot=false foo
  $ sleep 10 # allow booting
  $ lxc exec foo -- apt install -y software-properties-common
  $ lxc exec foo -- add-apt-repository -y ppa:wireguard/wireguard
  $ lxc exec foo -- apt install -y wireguard-tools

  $ cat << EOF | lxc exec foo -- tee /etc/systemd/network/wg0.netdev
  # foo
  [NetDev]
  Name=wg0
  Kind=wireguard

  [WireGuard]
  ListenPort=
  PrivateKey=cBkljQSKhtEe/U8GZmCAk2MBbKWL4TLC9PVtbMFyCVQ=

  [WireGuardPeer]
  PublicKey=emfIuZ3hZ+AnWIrKex/EqCp2mfzip8AxJu6RuweyRGc=
  AllowedIPs=192.168.255.2
  Endpoint=bar.lxd:
  EOF

  $ cat << EOF | lxc exec foo -- tee /etc/systemd/network/wg0.network
  # foo
  [Match]
  Name=wg0

  [Network]
  Address=192.168.255.1/24
  EOF

  $ lxc exec foo -- systemctl restart systemd-networkd

  # notice the invalid length in dmesg
  $ lxc exec foo -- journalctl -kn 8
  -- Logs begin at Mon 2020-05-11 16:56:40 UTC, end at Mon 2020-05-11 17:03:46 
UTC. --
  May 11 16:58:25 foo kernel: nf_tables: (c) 2007-2009 Patrick McHardy 

  May 11 17:01:57 foo kernel: PKCS#7 signature not signed with a trusted key
  May 11 17:01:57 foo kernel: wireguard: module verification failed: signature 
and/or required key missing - tainting kernel
  May 11 17:01:57 foo kernel: wireguard: WireGuard 1.0.20200429 loaded. See 
www.wireguard.com for information.
  May 11 17:01:57 foo kernel: wireguard: Copyright (C) 2015-2019 Jason A. 
Donenfeld . All Rights Reserved.
  May 11 17:01:57 foo kernel: netlink: 'systemd-network': attribute type 5 has 
an invalid length.
  May 11 17:01:57 foo kernel: netlink: 'systemd-network': attribute type 5 has 
an invalid length.
 

[Touch-packages] [Bug 1877159] Re: netlink: 'systemd-network': attribute type 5 has an invalid length.

2020-05-07 Thread Simon Déziel
Here is a strace of systemd-networkd when it was consuming 100% CPU:
https://paste.ubuntu.com/p/2XwxWwW99q/

-- 
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/1877159

Title:
  netlink: 'systemd-network': attribute type 5 has an invalid length.

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  New
Status in systemd source package in Eoan:
  Fix Released
Status in systemd source package in Focal:
  Fix Released

Bug description:
  This morning, our 2 Bionic machine configured with the wireguard's PPA
  and using systemd-networkd to configure the wireguard tunnel started
  misbehaving. Why this started just now is unclear ATM but their dmesg
  was filled with this:

  validate_nla: 100 callbacks suppressed
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.

  Folks in #systemd mentioned
  https://github.com/systemd/systemd/issues/11575 which points to 2
  commits missing from Bionic's systemd version:

  
https://github.com/systemd/systemd/commit/7d0b26a027118ca063780421cb31c74e9d2664ee
  
https://github.com/systemd/systemd/commit/624a47694cad4c87b2e807c32db656f3e9d679c5

  Focal's systemd have the above commits. Would it be possible to
  backport those 2 commits to Bionic?

  
  Additional information:

  # uname -a
  Linux noc-eu1 4.15.0-99-generic #100-Ubuntu SMP Wed Apr 22 20:32:56 UTC 2020 
x86_64 x86_64 x86_64 GNU/Linux

  # apt-cache policy systemd wireguard{,-tools,-dkms}
  systemd:
Installed: 237-3ubuntu10.39
Candidate: 237-3ubuntu10.39
Version table:
   *** 237-3ubuntu10.39 500
  500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   237-3ubuntu10.38 500
  500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 
Packages
   237-3ubuntu10 500
  500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages
  wireguard:
Installed: 1.0.20200319-1ubuntu1~18.04
Candidate: 1.0.20200319-1ubuntu1~18.04
Version table:
   *** 1.0.20200319-1ubuntu1~18.04 500
  500 http://ppa.launchpad.net/wireguard/wireguard/ubuntu bionic/main 
amd64 Packages
  500 http://ppa.launchpad.net/wireguard/wireguard/ubuntu bionic/main 
i386 Packages
  100 /var/lib/dpkg/status
  wireguard-tools:
Installed: 1.0.20200319-1ubuntu1~18.04
Candidate: 1.0.20200319-1ubuntu1~18.04
Version table:
   *** 1.0.20200319-1ubuntu1~18.04 500
  500 http://ppa.launchpad.net/wireguard/wireguard/ubuntu bionic/main 
amd64 Packages
  100 /var/lib/dpkg/status
  wireguard-dkms:
Installed: 1.0.20200429-2~18.04
Candidate: 1.0.20200429-2~18.04
Version table:
   *** 1.0.20200429-2~18.04 500
  500 http://ppa.launchpad.net/wireguard/wireguard/ubuntu bionic/main 
amd64 Packages
  500 http://ppa.launchpad.net/wireguard/wireguard/ubuntu bionic/main 
i386 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1877159/+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 1872564] Re: /proc/sys/kernel/random/boot_id rule missing from abstractions/nameservice

2020-05-06 Thread Simon Déziel
The missing rule for boot_id was added to Apparmor 2.13
(https://gitlab.com/apparmor/apparmor/-/blob/apparmor-2.13/profiles/apparmor.d/abstractions/nameservice#L35)
and was later refined in the master branch. As such, marking as fix
committed.


** Changed in: apparmor (Ubuntu)
   Status: New => Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1872564

Title:
  /proc/sys/kernel/random/boot_id rule missing from
  abstractions/nameservice

Status in apparmor package in Ubuntu:
  Fix Committed

Bug description:
  # Description

  On a default Focal install, systemd is used when looking up passwd and
  group information:

  # grep systemd /etc/nsswitch.conf 
  passwd: files systemd
  group:  files systemd

  Daemons confined by Apparmor that also query those "databases" will
  cause this Apparmor denial:

  audit: type=1400 audit(1586825456.411:247): apparmor="DENIED"
  operation="open" namespace="root//lxd-fb1_"
  profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id"
  pid=7370 comm="named" requested_mask="r" denied_mask="r" fsuid=100
  ouid=100

  Many daemons confined by Apparmor also happen to downgrade their
  privileges so they always end up looking up user/group information.

  # Steps to reproduce

  1) launch a Focal container (named fb1 here)
  $ lxc launch images:ubuntu/focal fb1

  2) setup apparmor inside the container (already done on official Ubuntu 
images)
  $ lxc exec fb1 -- apt update && lxc exec fb1 -- apt install apparmor -y

  3) install bind9
  $ lxc exec fb1 -- apt install bind9 -y

  4) check kernel logs for DENIED
  $ journalctl -o cat -b0 -k | grep 'apparmor="DENIED"' | grep -F 
'profile="/usr/sbin/named"'

  
  Step 4, should not return anything. Because systemd is involved in the 
user/group lookups, it currently returns the following:

  audit: type=1400 audit(1586826072.115:266): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:267): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:268): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:269): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:270): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100

  
  # Workaround

  1) remove systemd from nsswitch.conf
  $ lxc exec fb1 -- sed -i 's/ systemd$/ # systemd/' /etc/nsswitch.conf
  2) restart named
  $ lxc exec fb1 -- service named restart
  3) notice no more denials in kernel logs

  # Additional information

  root@fb1:~# apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu4
Candidate: 2.13.3-7ubuntu4
Version table:
   *** 2.13.3-7ubuntu4 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status

  root@fb1:~# uname -a
  Linux fb1 5.3.0-46-generic #38~18.04.1-Ubuntu SMP Tue Mar 31 04:17:56 UTC 
2020 x86_64 x86_64 x86_64 GNU/Linux

  root@fb1:~# lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:  20.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1872564/+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


Re: [Touch-packages] [Bug 1803601] Re: motd-news.service scheduled even when /etc/update-motd.d/50-motd-news is not executable

2020-05-06 Thread Simon Déziel
On 2020-05-06 2:49 p.m., Andreas Hasenack wrote:
> There are many alternatives here.

IIRC, `chmod -x` snippets from /etc/update-motd.d/ was the way to go a
few releases ago when it was consumed by run-parts.

> I think fixing this doesn't warrant an SRU, but should be considered for
> the devel release of ubuntu (groovy at the moment).

It's merely to avoid harmless surprise and keep the old sysadmins happy,
certainly not worth a SRU.

Thanks,
Simon

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to base-files in Ubuntu.
https://bugs.launchpad.net/bugs/1803601

Title:
  motd-news.service scheduled even when /etc/update-motd.d/50-motd-news
  is not executable

Status in base-files package in Ubuntu:
  Triaged

Bug description:
  update-motd(5) says:

   Executable scripts in /etc/update-motd.d/* are executed by pam_motd(8) as 
the root user at each
   login, and this information is concatenated in /run/motd.dynamic.  The order 
of  script  execu‐
   tion is determined by the run-parts(8) --lsbsysinit option (basically 
alphabetical order, with
   a few caveats).

  So sysadmins are used to "chmod -x" motd fragments from /etc/update-
  motd.d/ to prevent their execution. When doing so for /etc/update-
  motd.d/50-motd-news, I noticed that motd-news.timer was still trying
  to execute the motd-news.service unit which then logged a failure:

   systemd[3704]: motd-news.service: Failed to execute command: Permission 
denied
   systemd[3704]: motd-news.service: Failed at step EXEC spawning 
/etc/update-motd.d/50-motd-news:
    Permission denied
   systemd[1]: motd-news.service: Main process exited, code=exited, 
status=203/EXEC
   systemd[1]: motd-news.service: Failed with result 'exit-code'.
   systemd[1]: Failed to start Message of the Day.

  
  The motd-news.service unit looks like this:

  $ systemctl cat motd-news.service
  # /lib/systemd/system/motd-news.service
  [Unit]
  Description=Message of the Day
  After=network-online.target
  Documentation=man:update-motd(8)

  [Service]
  Type=oneshot
  ExecStart=/etc/update-motd.d/50-motd-news --force

  
  This problem was observed on a Bionic system:

  $ lsb_release -rd
  Description:  Ubuntu 18.04.1 LTS
  Release:  18.04
  $ apt-cache policy base-files
  base-files:
    Installed: 10.1ubuntu2.3
    Candidate: 10.1ubuntu2.3
    Version table:
   *** 10.1ubuntu2.3 500
  500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   10.1ubuntu2.2 500
  500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 
Packages
   10.1ubuntu2 500
  500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages

  But the problem also exist in Disco.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1803601/+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 1877159] [NEW] netlink: 'systemd-network': attribute type 5 has an invalid length.

2020-05-06 Thread Simon Déziel
Public bug reported:

This morning, our 2 Bionic machine configured with the wireguard's PPA
and using systemd-networkd to configure the wireguard tunnel started
misbehaving. Why this started just now is unclear ATM but their dmesg
was filled with this:

validate_nla: 100 callbacks suppressed
netlink: 'systemd-network': attribute type 5 has an invalid length.
netlink: 'systemd-network': attribute type 5 has an invalid length.
netlink: 'systemd-network': attribute type 5 has an invalid length.
netlink: 'systemd-network': attribute type 5 has an invalid length.
netlink: 'systemd-network': attribute type 5 has an invalid length.
netlink: 'systemd-network': attribute type 5 has an invalid length.
netlink: 'systemd-network': attribute type 5 has an invalid length.
netlink: 'systemd-network': attribute type 5 has an invalid length.
netlink: 'systemd-network': attribute type 5 has an invalid length.
netlink: 'systemd-network': attribute type 5 has an invalid length.

Folks in #systemd mentioned
https://github.com/systemd/systemd/issues/11575 which points to 2
commits missing from Bionic's systemd version:

https://github.com/systemd/systemd/commit/7d0b26a027118ca063780421cb31c74e9d2664ee
https://github.com/systemd/systemd/commit/624a47694cad4c87b2e807c32db656f3e9d679c5

Focal's systemd have the above commits. Would it be possible to backport
those 2 commits to Bionic?


Additional information:

# uname -a
Linux noc-eu1 4.15.0-99-generic #100-Ubuntu SMP Wed Apr 22 20:32:56 UTC 2020 
x86_64 x86_64 x86_64 GNU/Linux

# apt-cache policy systemd wireguard{,-tools,-dkms}
systemd:
  Installed: 237-3ubuntu10.39
  Candidate: 237-3ubuntu10.39
  Version table:
 *** 237-3ubuntu10.39 500
500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
100 /var/lib/dpkg/status
 237-3ubuntu10.38 500
500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 
Packages
 237-3ubuntu10 500
500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages
wireguard:
  Installed: 1.0.20200319-1ubuntu1~18.04
  Candidate: 1.0.20200319-1ubuntu1~18.04
  Version table:
 *** 1.0.20200319-1ubuntu1~18.04 500
500 http://ppa.launchpad.net/wireguard/wireguard/ubuntu bionic/main 
amd64 Packages
500 http://ppa.launchpad.net/wireguard/wireguard/ubuntu bionic/main 
i386 Packages
100 /var/lib/dpkg/status
wireguard-tools:
  Installed: 1.0.20200319-1ubuntu1~18.04
  Candidate: 1.0.20200319-1ubuntu1~18.04
  Version table:
 *** 1.0.20200319-1ubuntu1~18.04 500
500 http://ppa.launchpad.net/wireguard/wireguard/ubuntu bionic/main 
amd64 Packages
100 /var/lib/dpkg/status
wireguard-dkms:
  Installed: 1.0.20200429-2~18.04
  Candidate: 1.0.20200429-2~18.04
  Version table:
 *** 1.0.20200429-2~18.04 500
500 http://ppa.launchpad.net/wireguard/wireguard/ubuntu bionic/main 
amd64 Packages
500 http://ppa.launchpad.net/wireguard/wireguard/ubuntu bionic/main 
i386 Packages
100 /var/lib/dpkg/status

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Status: New

-- 
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/1877159

Title:
  netlink: 'systemd-network': attribute type 5 has an invalid length.

Status in systemd package in Ubuntu:
  New

Bug description:
  This morning, our 2 Bionic machine configured with the wireguard's PPA
  and using systemd-networkd to configure the wireguard tunnel started
  misbehaving. Why this started just now is unclear ATM but their dmesg
  was filled with this:

  validate_nla: 100 callbacks suppressed
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.
  netlink: 'systemd-network': attribute type 5 has an invalid length.

  Folks in #systemd mentioned
  https://github.com/systemd/systemd/issues/11575 which points to 2
  commits missing from Bionic's systemd version:

  
https://github.com/systemd/systemd/commit/7d0b26a027118ca063780421cb31c74e9d2664ee
  
https://github.com/systemd/systemd/commit/624a47694cad4c87b2e807c32db656f3e9d679c5

  Focal's systemd have the above commits. Would it be possible to
  backport those 2 commits to Bionic?

  
  Additional information:

  # uname -a
  Linux noc-eu1 4.15.0-99-generic #100-Ubuntu SMP Wed Apr 22 20:32:56 UTC 2020 
x86_64 x86_64 x86_64 GNU/Linux

  # apt-cache policy systemd 

[Touch-packages] [Bug 1872564] Re: /proc/sys/kernel/random/boot_id rule missing from abstractions/nameservice

2020-05-04 Thread Simon Déziel
squid in focal is indeed another package that triggers that denial but
it is non fatal there as mentioned by Andreas.

@ahasenack, with 4.11, squid's systemd unit moved from Type=forking to
Type=notify and with the error you showed, I would expect you to see a
denial trying to write to /run/systemd/notify. I don't think a rule for
/run/systemd/notify was added in any abstraction (yet) and I don't see
any such rule in squid's profile itself.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1872564

Title:
  /proc/sys/kernel/random/boot_id rule missing from
  abstractions/nameservice

Status in apparmor package in Ubuntu:
  New

Bug description:
  # Description

  On a default Focal install, systemd is used when looking up passwd and
  group information:

  # grep systemd /etc/nsswitch.conf 
  passwd: files systemd
  group:  files systemd

  Daemons confined by Apparmor that also query those "databases" will
  cause this Apparmor denial:

  audit: type=1400 audit(1586825456.411:247): apparmor="DENIED"
  operation="open" namespace="root//lxd-fb1_"
  profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id"
  pid=7370 comm="named" requested_mask="r" denied_mask="r" fsuid=100
  ouid=100

  Many daemons confined by Apparmor also happen to downgrade their
  privileges so they always end up looking up user/group information.

  # Steps to reproduce

  1) launch a Focal container (named fb1 here)
  $ lxc launch images:ubuntu/focal fb1

  2) setup apparmor inside the container (already done on official Ubuntu 
images)
  $ lxc exec fb1 -- apt update && lxc exec fb1 -- apt install apparmor -y

  3) install bind9
  $ lxc exec fb1 -- apt install bind9 -y

  4) check kernel logs for DENIED
  $ journalctl -o cat -b0 -k | grep 'apparmor="DENIED"' | grep -F 
'profile="/usr/sbin/named"'

  
  Step 4, should not return anything. Because systemd is involved in the 
user/group lookups, it currently returns the following:

  audit: type=1400 audit(1586826072.115:266): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:267): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:268): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:269): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:270): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100

  
  # Workaround

  1) remove systemd from nsswitch.conf
  $ lxc exec fb1 -- sed -i 's/ systemd$/ # systemd/' /etc/nsswitch.conf
  2) restart named
  $ lxc exec fb1 -- service named restart
  3) notice no more denials in kernel logs

  # Additional information

  root@fb1:~# apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu4
Candidate: 2.13.3-7ubuntu4
Version table:
   *** 2.13.3-7ubuntu4 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status

  root@fb1:~# uname -a
  Linux fb1 5.3.0-46-generic #38~18.04.1-Ubuntu SMP Tue Mar 31 04:17:56 UTC 
2020 x86_64 x86_64 x86_64 GNU/Linux

  root@fb1:~# lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:  20.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1872564/+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 1872564] Re: /proc/sys/kernel/random/boot_id rule missing from abstractions/nameservice

2020-05-04 Thread Simon Déziel
`snap info lxd` says:
installed:  4.0.1  (14890) 72MB -

And indeed, there is a tmpfs mounted there:

root@bind:~# mount | grep boot
none on /proc/sys/kernel/random/boot_id type tmpfs 
(ro,nosuid,nodev,noexec,relatime,size=492k,mode=755,uid=1524288,gid=1524288)

That said, I don't think there is anything lxd specific to this issue as
similar behavior is observable on physical/virtual machines where lxd is
not used at all.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1872564

Title:
  /proc/sys/kernel/random/boot_id rule missing from
  abstractions/nameservice

Status in apparmor package in Ubuntu:
  New

Bug description:
  # Description

  On a default Focal install, systemd is used when looking up passwd and
  group information:

  # grep systemd /etc/nsswitch.conf 
  passwd: files systemd
  group:  files systemd

  Daemons confined by Apparmor that also query those "databases" will
  cause this Apparmor denial:

  audit: type=1400 audit(1586825456.411:247): apparmor="DENIED"
  operation="open" namespace="root//lxd-fb1_"
  profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id"
  pid=7370 comm="named" requested_mask="r" denied_mask="r" fsuid=100
  ouid=100

  Many daemons confined by Apparmor also happen to downgrade their
  privileges so they always end up looking up user/group information.

  # Steps to reproduce

  1) launch a Focal container (named fb1 here)
  $ lxc launch images:ubuntu/focal fb1

  2) setup apparmor inside the container (already done on official Ubuntu 
images)
  $ lxc exec fb1 -- apt update && lxc exec fb1 -- apt install apparmor -y

  3) install bind9
  $ lxc exec fb1 -- apt install bind9 -y

  4) check kernel logs for DENIED
  $ journalctl -o cat -b0 -k | grep 'apparmor="DENIED"' | grep -F 
'profile="/usr/sbin/named"'

  
  Step 4, should not return anything. Because systemd is involved in the 
user/group lookups, it currently returns the following:

  audit: type=1400 audit(1586826072.115:266): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:267): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:268): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:269): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:270): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100

  
  # Workaround

  1) remove systemd from nsswitch.conf
  $ lxc exec fb1 -- sed -i 's/ systemd$/ # systemd/' /etc/nsswitch.conf
  2) restart named
  $ lxc exec fb1 -- service named restart
  3) notice no more denials in kernel logs

  # Additional information

  root@fb1:~# apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu4
Candidate: 2.13.3-7ubuntu4
Version table:
   *** 2.13.3-7ubuntu4 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status

  root@fb1:~# uname -a
  Linux fb1 5.3.0-46-generic #38~18.04.1-Ubuntu SMP Tue Mar 31 04:17:56 UTC 
2020 x86_64 x86_64 x86_64 GNU/Linux

  root@fb1:~# lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:  20.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1872564/+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 1876320] Re: Port parameter sshd_config is 22 AND whatever you specify

2020-05-01 Thread Simon Déziel
On a stock install, adding "Port 7722" to /etc/ssh/sshd_config and
restarting sshd gives me this:

# ss -nltp | grep sshd
LISTEN0 128 0.0.0.0:77220.0.0.0:* 
users:(("sshd",pid=10651,fd=3))
LISTEN0 128 [::]:7722   [::]:*
users:(("sshd",pid=10651,fd=4)) 

So 1 daemon, bounding to port 7722 on IPv4 and IPv6 wildcards.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1876320

Title:
  Port parameter sshd_config is 22 AND whatever you specify

Status in openssh package in Ubuntu:
  New

Bug description:
  On my Ubuntu Server 20.04 LTS with OpenSSH 1:8.2p1-4, I have TWO sshd
  deamons. One (on port 22) is for internal use, accepts passwords etc.
  The second (on port 7722) does not allow PAM use and no passwords,
  allows only one user(name) and uses an alternative autorized_keys file
  (that only root can edit).

  Any parameter FIRST encountered in sshd_config is the one that is
  accepted; others do not override (like in many other config files).
  There is one exception: 'Port', which is accumulative. To make life
  easier, I set the more restrictive parameters for port 7722 first and
  next include the system-default /etc/ssh/sshd_config.

  The /etc/ssh/sshd_config file(s) in Ubuntu Server 20.04 DO NOT specify
  'Port' anywhere - the default is 22. But: it is obviously still
  accumulative: Setting 'Port' to 7722 makes sshd listen on port 7722
  AND 22. This is unwanted.

  Proposed solution: Remove the accumulative behavior for 'Port' and
  REQUIRE the 'Port' parameter like before (and maybe have second and
  later parameters override the earlier ones, like 'everyone else').

  Regards,

  Adriaan

  PS Searching for solutions, I found that specifying 'ListenAddress
  0.0.0.0:7722' stops sshd from listening to port 22. This, however, is
  not documented in 'man 5 sshd_config' and may be an unreliable side-
  effect.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1876320/+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 1876320] Re: Port parameter sshd_config is 22 AND whatever you specify

2020-05-01 Thread Simon Déziel
@Adriaan, are there really 2 sshd running? Or is it only one binding to
the 2 ports and applying different parameter using Match conditions?
Beware what on 20.04, there is support for additional config snippets
dropped in /etc/ssh/sshd_config.d/*.conf.

To check for 2 daemons:

sudo ss -nltp | grep sshd

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1876320

Title:
  Port parameter sshd_config is 22 AND whatever you specify

Status in openssh package in Ubuntu:
  New

Bug description:
  On my Ubuntu Server 20.04 LTS with OpenSSH 1:8.2p1-4, I have TWO sshd
  deamons. One (on port 22) is for internal use, accepts passwords etc.
  The second (on port 7722) does not allow PAM use and no passwords,
  allows only one user(name) and uses an alternative autorized_keys file
  (that only root can edit).

  Any parameter FIRST encountered in sshd_config is the one that is
  accepted; others do not override (like in many other config files).
  There is one exception: 'Port', which is accumulative. To make life
  easier, I set the more restrictive parameters for port 7722 first and
  next include the system-default /etc/ssh/sshd_config.

  The /etc/ssh/sshd_config file(s) in Ubuntu Server 20.04 DO NOT specify
  'Port' anywhere - the default is 22. But: it is obviously still
  accumulative: Setting 'Port' to 7722 makes sshd listen on port 7722
  AND 22. This is unwanted.

  Proposed solution: Remove the accumulative behavior for 'Port' and
  REQUIRE the 'Port' parameter like before (and maybe have second and
  later parameters override the earlier ones, like 'everyone else').

  Regards,

  Adriaan

  PS Searching for solutions, I found that specifying 'ListenAddress
  0.0.0.0:7722' stops sshd from listening to port 22. This, however, is
  not documented in 'man 5 sshd_config' and may be an unreliable side-
  effect.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1876320/+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 1875644] [NEW] motd-news complains that curl is missing

2020-04-28 Thread Simon Déziel
Public bug reported:

Description:

motd-news complains that curl is missing on every run. motd-news.timer
firing every ~12 hours, this useless message ends up in the logs
regularly.

Steps to reproduce:

$ lxc launch images:ubuntu/focal motd
Creating motd
Starting motd
$ lxc exec motd -- /etc/update-motd.d/50-motd-news --force
dpkg-query: no packages found matching curl

This should output nothing.

Additional information:

# lsb_release -rd
Description:Ubuntu 20.04 LTS
Release:20.04

# apt-cache policy base-files
base-files:
  Installed: 11ubuntu5
  Candidate: 11ubuntu5
  Version table:
 *** 11ubuntu5 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status

** Affects: base-files (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to base-files in Ubuntu.
https://bugs.launchpad.net/bugs/1875644

Title:
  motd-news complains that curl is missing

Status in base-files package in Ubuntu:
  New

Bug description:
  Description:

  motd-news complains that curl is missing on every run. motd-news.timer
  firing every ~12 hours, this useless message ends up in the logs
  regularly.

  Steps to reproduce:

  $ lxc launch images:ubuntu/focal motd
  Creating motd
  Starting motd
  $ lxc exec motd -- /etc/update-motd.d/50-motd-news --force
  dpkg-query: no packages found matching curl

  This should output nothing.

  Additional information:

  # lsb_release -rd
  Description:  Ubuntu 20.04 LTS
  Release:  20.04

  # apt-cache policy base-files
  base-files:
Installed: 11ubuntu5
Candidate: 11ubuntu5
Version table:
   *** 11ubuntu5 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1875644/+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 1872564] Re: /proc/sys/kernel/random/boot_id rule missing from abstractions/nameservice

2020-04-15 Thread Simon Déziel
Scratch that. Using 'owner' on a root-owned but world readable file is
probably ill-advised in an abstraction. It seems plausible for an
application to do NSS lookup for user/group while running as non-root.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1872564

Title:
  /proc/sys/kernel/random/boot_id rule missing from
  abstractions/nameservice

Status in apparmor package in Ubuntu:
  New

Bug description:
  # Description

  On a default Focal install, systemd is used when looking up passwd and
  group information:

  # grep systemd /etc/nsswitch.conf 
  passwd: files systemd
  group:  files systemd

  Daemons confined by Apparmor that also query those "databases" will
  cause this Apparmor denial:

  audit: type=1400 audit(1586825456.411:247): apparmor="DENIED"
  operation="open" namespace="root//lxd-fb1_"
  profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id"
  pid=7370 comm="named" requested_mask="r" denied_mask="r" fsuid=100
  ouid=100

  Many daemons confined by Apparmor also happen to downgrade their
  privileges so they always end up looking up user/group information.

  # Steps to reproduce

  1) launch a Focal container (named fb1 here)
  $ lxc launch images:ubuntu/focal fb1

  2) setup apparmor inside the container (already done on official Ubuntu 
images)
  $ lxc exec fb1 -- apt update && lxc exec fb1 -- apt install apparmor -y

  3) install bind9
  $ lxc exec fb1 -- apt install bind9 -y

  4) check kernel logs for DENIED
  $ journalctl -o cat -b0 -k | grep 'apparmor="DENIED"' | grep -F 
'profile="/usr/sbin/named"'

  
  Step 4, should not return anything. Because systemd is involved in the 
user/group lookups, it currently returns the following:

  audit: type=1400 audit(1586826072.115:266): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:267): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:268): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:269): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:270): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100

  
  # Workaround

  1) remove systemd from nsswitch.conf
  $ lxc exec fb1 -- sed -i 's/ systemd$/ # systemd/' /etc/nsswitch.conf
  2) restart named
  $ lxc exec fb1 -- service named restart
  3) notice no more denials in kernel logs

  # Additional information

  root@fb1:~# apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu4
Candidate: 2.13.3-7ubuntu4
Version table:
   *** 2.13.3-7ubuntu4 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status

  root@fb1:~# uname -a
  Linux fb1 5.3.0-46-generic #38~18.04.1-Ubuntu SMP Tue Mar 31 04:17:56 UTC 
2020 x86_64 x86_64 x86_64 GNU/Linux

  root@fb1:~# lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:  20.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1872564/+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 1872564] Re: /proc/sys/kernel/random/boot_id rule missing from abstractions/nameservice

2020-04-15 Thread Simon Déziel
On all my machines and using various daemons, the denial messages always
have fsuid==ouid. As such, I believe it would be OK to use the 'owner'
specifier like this:

  owner @{PROC}/sys/kernel/random/boot_id r,

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1872564

Title:
  /proc/sys/kernel/random/boot_id rule missing from
  abstractions/nameservice

Status in apparmor package in Ubuntu:
  New

Bug description:
  # Description

  On a default Focal install, systemd is used when looking up passwd and
  group information:

  # grep systemd /etc/nsswitch.conf 
  passwd: files systemd
  group:  files systemd

  Daemons confined by Apparmor that also query those "databases" will
  cause this Apparmor denial:

  audit: type=1400 audit(1586825456.411:247): apparmor="DENIED"
  operation="open" namespace="root//lxd-fb1_"
  profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id"
  pid=7370 comm="named" requested_mask="r" denied_mask="r" fsuid=100
  ouid=100

  Many daemons confined by Apparmor also happen to downgrade their
  privileges so they always end up looking up user/group information.

  # Steps to reproduce

  1) launch a Focal container (named fb1 here)
  $ lxc launch images:ubuntu/focal fb1

  2) setup apparmor inside the container (already done on official Ubuntu 
images)
  $ lxc exec fb1 -- apt update && lxc exec fb1 -- apt install apparmor -y

  3) install bind9
  $ lxc exec fb1 -- apt install bind9 -y

  4) check kernel logs for DENIED
  $ journalctl -o cat -b0 -k | grep 'apparmor="DENIED"' | grep -F 
'profile="/usr/sbin/named"'

  
  Step 4, should not return anything. Because systemd is involved in the 
user/group lookups, it currently returns the following:

  audit: type=1400 audit(1586826072.115:266): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:267): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:268): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:269): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100
  audit: type=1400 audit(1586826072.115:270): apparmor="DENIED" 
operation="open" namespace="root//lxd-fb1_" 
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 
comm="named" requested_mask="r" denied_mask="r" fsuid=100 ouid=100

  
  # Workaround

  1) remove systemd from nsswitch.conf
  $ lxc exec fb1 -- sed -i 's/ systemd$/ # systemd/' /etc/nsswitch.conf
  2) restart named
  $ lxc exec fb1 -- service named restart
  3) notice no more denials in kernel logs

  # Additional information

  root@fb1:~# apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu4
Candidate: 2.13.3-7ubuntu4
Version table:
   *** 2.13.3-7ubuntu4 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status

  root@fb1:~# uname -a
  Linux fb1 5.3.0-46-generic #38~18.04.1-Ubuntu SMP Tue Mar 31 04:17:56 UTC 
2020 x86_64 x86_64 x86_64 GNU/Linux

  root@fb1:~# lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:  20.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1872564/+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 1827253] Re: [apparmor] missing 'mr' on binary for usage on containers

2020-04-15 Thread Simon Déziel
The 1st SRU for Bionic failed because I typo'ed the path to the binary (rsyslog 
!= rsyslogd).
Focal is fixed and Bionic is left with a 'bad' package in bionic-proposed. I 
don't think redoing the SRU for Bionic is worth it, it's a default *disabled* 
profile after all.

I'd leave things as is or maybe delete the bionic-proposed package as
cleanup if that's easy.

Thanks Rafael!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1827253

Title:
  [apparmor] missing 'mr' on binary for usage on containers

Status in rsyslog package in Ubuntu:
  Fix Released
Status in rsyslog source package in Bionic:
  In Progress
Status in rsyslog source package in Disco:
  In Progress
Status in rsyslog source package in Eoan:
  In Progress

Bug description:
  [Impact]

   * rsyslog ships with a (Default disable) apparmor profile.
   * Security sensitive users are in general encouraged to enable such
     profiles but unfortunately due to slightly new behavior of the program
     the profile prevents its usage.
   * Allow the program to map/read its binary to get this working again

  [Test Case]

  1) Create a 'eoan' container called rs1 here:
    lxc launch ubuntu-daily:e rs1
  2) Enter the container
    lxc shell rs1
  3) Enable apparmor profile
    rm /etc/apparmor.d/disable/usr.sbin.rsyslogd
    apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
    systemctl restart rsyslog
  4) notice rsyslog failed to start
    systemctl status rsyslog

  [Regression Potential]

   * This is just opening up the apparmor profile a bit. Therefore the only
     regression it could cause IMHO is a security issue. But then what it
     actually allows is reading (not writing!) its own binary which should
     be very safe.
   * Thinking further it came to my mind that package updates (independent 
 to the change) might restart services and that means if there is any 
 issue e.g. in a local config that worked but now fails (not by this 
 change but in general) then the upgrade will not cause, but trigger 
 this. This is a general regression risk for any upload, but in this 
 case worth to mention as it is about log handling - which if broken - 
 makes large scale systems hard to debug.

  [Other Info]

   * n/a

  ---

  Issue description:

  Enabling the rsyslog (disabled by default) Apparmor profile causes
  rsyslog to fail to start when running *inside a container*.

  Steps to reproduce:

  1) Create a 'eoan' container called rs1 here:
    lxc launch ubuntu-daily:e rs1
  2) Enter the container
    lxc shell rs1
  3) Enable apparmor profile
    rm /etc/apparmor.d/disable/usr.sbin.rsyslogd
    apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
    systemctl restart rsyslog
  4) notice rsyslog failed to start
    systemctl status rsyslog

  Workaround:

    echo '  /usr/sbin/rsyslogd mr,' >> /etc/apparmor.d/local/usr.sbin.rsyslogd
    apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
    systemctl restart rsyslog

  Additional information:

  root@rs1:~# uname -a
  Linux rs1 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 
x86_64 x86_64 GNU/Linux
  root@rs1:~# lsb_release -rd
  Description:  Ubuntu Eoan EANIMAL (development branch)
  Release:  19.10
  root@rs1:~# dpkg -l| grep -wE 'apparmor|rsyslog'
  ii  apparmor 2.13.2-9ubuntu6  amd64user-space parser utility for 
AppArmor
  ii  rsyslog  8.32.0-1ubuntu7  amd64reliable system and kernel logging 
daemon

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: rsyslog 8.32.0-1ubuntu7
  ProcVersionSignature: Ubuntu 4.15.0-48.51-generic 4.15.18
  Uname: Linux 4.15.0-48-generic x86_64
  ApportVersion: 2.20.10-0ubuntu27
  Architecture: amd64
  Date: Wed May  1 17:36:29 2019
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: rsyslog
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1827253/+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 1860461] Re: libgnutls30 3.6.11.1-2ubuntu2 (Ubuntu 20.04) breaks pulseui client with error "Error performing TLS handshake: The Diffie-Hellman prime sent by the server is not acc

2020-04-14 Thread Simon Déziel
Oops, it should have been LOW, not LEGACY. Here it is again to avoid any
confusion:

As a workaround, can you try lowering the profile from MEDIUM [1] to LOW
[2]:

sudo mkdir /etc/gnutls
cat << EOF | sudo tee -a /etc/gnutls/config
[overrides]
default-priority-string = 
NORMAL:-VERS-ALL:+VERS-TLS1.3:+VERS-TLS1.2:+VERS-DTLS1.2:%PROFILE_LOW
EOF


1: https://git.launchpad.net/ubuntu/+source/gnutls28/tree/debian/rules#n38
2: 
https://gnutls.org/manual/html_node/Selecting-cryptographic-key-sizes.html#Selecting-cryptographic-key-sizes

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnome-online-accounts in
Ubuntu.
https://bugs.launchpad.net/bugs/1860461

Title:
  libgnutls30 3.6.11.1-2ubuntu2 (Ubuntu 20.04) breaks pulseui client
  with error "Error performing TLS handshake: The Diffie-Hellman prime
  sent by the server is not acceptable (not long enough)."

Status in evolution package in Ubuntu:
  Confirmed
Status in gnome-online-accounts package in Ubuntu:
  Confirmed
Status in gnutls28 package in Ubuntu:
  Incomplete

Bug description:
  After upgrade to 20.04 package libgnutls30 broke pulseUI VPN client
  with the following error:

  "Error performing TLS handshake: The Diffie-Hellman prime sent by the
  server is not acceptable (not long enough)."

  I had to revert the package to the 19.10 version (3.6.9-5ubuntu1) and
  to install 19.10 dependency libhogweed4 3.4.1-1 to fix it.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: libgnutls30 3.6.9-5ubuntu1
  ProcVersionSignature: Ubuntu 5.4.0-9.12-generic 5.4.3
  Uname: Linux 5.4.0-9-generic x86_64
  ApportVersion: 2.20.11-0ubuntu15
  Architecture: amd64
  Date: Tue Jan 21 17:48:39 2020
  InstallationDate: Installed on 2017-06-21 (943 days ago)
  InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
  SourcePackage: gnutls28
  UpgradeStatus: Upgraded to focal on 2020-01-10 (10 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/1860461/+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 1866974] Re: The Diffie-Hellman prime sent by the server is not acceptable

2020-04-14 Thread Simon Déziel
*** This bug is a duplicate of bug 1872778 ***
https://bugs.launchpad.net/bugs/1872778

As a workaround, can you try lowering the profile from MEDIUM [1] to LOW
[2]:

sudo mkdir /etc/gnutls
cat << EOF | sudo tee -a /etc/gnutls/config
[overrides]
default-priority-string = 
NORMAL:-VERS-ALL:+VERS-TLS1.3:+VERS-TLS1.2:+VERS-DTLS1.2:%PROFILE_LOW
EOF


1: https://git.launchpad.net/ubuntu/+source/gnutls28/tree/debian/rules#n38
2: 
https://gnutls.org/manual/html_node/Selecting-cryptographic-key-sizes.html#Selecting-cryptographic-key-sizes

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnome-online-accounts in
Ubuntu.
https://bugs.launchpad.net/bugs/1866974

Title:
  The Diffie-Hellman prime sent by the server is not acceptable

Status in evolution package in Ubuntu:
  Confirmed
Status in gnome-online-accounts package in Ubuntu:
  New

Bug description:
  I can no longer connect to my ISP mail server.
  Works in previous version 19.10

  "The reported error was “Failed to get capabilities: Error performing
  TLS handshake: The Diffie-Hellman prime sent by the server is not
  acceptable (not long enough).”."

  I've tried finding a workaround but so far no luck.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: evolution 3.35.92-1
  ProcVersionSignature: Ubuntu 5.4.0-18.22-generic 5.4.24
  Uname: Linux 5.4.0-18-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.11-0ubuntu20
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Mar 11 11:07:01 2020
  InstallationDate: Installed on 2020-03-03 (7 days ago)
  InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200303)
  SourcePackage: evolution
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/1866974/+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 1860461] Re: libgnutls30 3.6.11.1-2ubuntu2 (Ubuntu 20.04) breaks pulseui client with error "Error performing TLS handshake: The Diffie-Hellman prime sent by the server is not acc

2020-04-14 Thread Simon Déziel
As a workaround, can you try lowering the profile from MEDIUM [1] to
LEGACY:

sudo mkdir /etc/gnutls
cat << EOF | sudo tee -a /etc/gnutls/config
[overrides]
default-priority-string = 
NORMAL:-VERS-ALL:+VERS-TLS1.3:+VERS-TLS1.2:+VERS-DTLS1.2:%PROFILE_LEGACY
EOF


1:
https://git.launchpad.net/ubuntu/+source/gnutls28/tree/debian/rules#n38

** Changed in: gnutls28 (Ubuntu)
   Status: Confirmed => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnome-online-accounts in
Ubuntu.
https://bugs.launchpad.net/bugs/1860461

Title:
  libgnutls30 3.6.11.1-2ubuntu2 (Ubuntu 20.04) breaks pulseui client
  with error "Error performing TLS handshake: The Diffie-Hellman prime
  sent by the server is not acceptable (not long enough)."

Status in evolution package in Ubuntu:
  Confirmed
Status in gnome-online-accounts package in Ubuntu:
  Confirmed
Status in gnutls28 package in Ubuntu:
  Incomplete

Bug description:
  After upgrade to 20.04 package libgnutls30 broke pulseUI VPN client
  with the following error:

  "Error performing TLS handshake: The Diffie-Hellman prime sent by the
  server is not acceptable (not long enough)."

  I had to revert the package to the 19.10 version (3.6.9-5ubuntu1) and
  to install 19.10 dependency libhogweed4 3.4.1-1 to fix it.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: libgnutls30 3.6.9-5ubuntu1
  ProcVersionSignature: Ubuntu 5.4.0-9.12-generic 5.4.3
  Uname: Linux 5.4.0-9-generic x86_64
  ApportVersion: 2.20.11-0ubuntu15
  Architecture: amd64
  Date: Tue Jan 21 17:48:39 2020
  InstallationDate: Installed on 2017-06-21 (943 days ago)
  InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
  SourcePackage: gnutls28
  UpgradeStatus: Upgraded to focal on 2020-01-10 (10 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/1860461/+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 1860461] Re: libgnutls30 3.6.11.1-2ubuntu2 (Ubuntu 20.04) breaks pulseui client with error "Error performing TLS handshake: The Diffie-Hellman prime sent by the server is not acc

2020-04-14 Thread Simon Déziel
** This bug is no longer a duplicate of bug 1872778
   update-crypto-policies not affecting Gnome Online Accounts

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnome-online-accounts in
Ubuntu.
https://bugs.launchpad.net/bugs/1860461

Title:
  libgnutls30 3.6.11.1-2ubuntu2 (Ubuntu 20.04) breaks pulseui client
  with error "Error performing TLS handshake: The Diffie-Hellman prime
  sent by the server is not acceptable (not long enough)."

Status in evolution package in Ubuntu:
  Confirmed
Status in gnome-online-accounts package in Ubuntu:
  Confirmed
Status in gnutls28 package in Ubuntu:
  Incomplete

Bug description:
  After upgrade to 20.04 package libgnutls30 broke pulseUI VPN client
  with the following error:

  "Error performing TLS handshake: The Diffie-Hellman prime sent by the
  server is not acceptable (not long enough)."

  I had to revert the package to the 19.10 version (3.6.9-5ubuntu1) and
  to install 19.10 dependency libhogweed4 3.4.1-1 to fix it.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: libgnutls30 3.6.9-5ubuntu1
  ProcVersionSignature: Ubuntu 5.4.0-9.12-generic 5.4.3
  Uname: Linux 5.4.0-9-generic x86_64
  ApportVersion: 2.20.11-0ubuntu15
  Architecture: amd64
  Date: Tue Jan 21 17:48:39 2020
  InstallationDate: Installed on 2017-06-21 (943 days ago)
  InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
  SourcePackage: gnutls28
  UpgradeStatus: Upgraded to focal on 2020-01-10 (10 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/1860461/+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


Re: [Touch-packages] [Bug 1869024] Re: add support for DynamicUser feature of systemd

2020-04-13 Thread Simon Déziel
On 2020-04-11 9:04 p.m., Simon Déziel wrote:
> On 2020-04-10 1:16 p.m., Jamie Strandboge wrote:
>> The abstraction is meant to cover the client, not systemd internal
>> specifics. A client simply accessing that DBus API won't need it and a
>> client simply accessing those sockets won't need it. It very well might
>> be that a profiled application is using some *ctl command from systemd
>> that would need it, but in that case said command would need to be added
>> to the policy and the boot-id could be added at that time.
> 
> I don't know as squid, named and samba (to name a few) generate many
> denials trying to read /proc/sys/kernel/random/boot_id. None of those
> are explicitly trying to use the DynamicUser feature. Could it be just a
> side effect of how nsswitch.conf is setup by default?
> 
> $ grep systemd /etc/nsswitch.conf
> passwd: files systemd
> group:  files systemd

This is indeed due to having systemd in the default nsswitch.conf. I've
report the problem in LP: #1872564

Simon

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1869024

Title:
  add support for DynamicUser feature of systemd

Status in snapd:
  In Progress
Status in apparmor package in Ubuntu:
  Fix Released

Bug description:
  systemd offers to create dynamic (and semi-stable) users for services.
  This causes many services using Apparmor profiles to trigger those
  denials (even when they don't use the DynamicUser feature):

  audit: type=1107 audit(1585076282.591:30): pid=621 uid=103
  auid=4294967295 ses=4294967295 msg='apparmor="DENIED"
  operation="dbus_method_call"  bus="system"
  path="/org/freedesktop/systemd1"
  interface="org.freedesktop.systemd1.Manager" member="GetDynamicUsers"
  mask="send" name="org.freedesktop.systemd1" pid=709
  label="/usr/sbin/squid" peer_pid=1 peer_label="unconfined"

  And more recently with systemd 245 this also get shown:

  audit: type=1400 audit(1585139000.628:39): apparmor="DENIED"
  operation="open" profile="/usr/sbin/squid" name="/run/systemd/userdb/"
  pid=769 comm="squid" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

  
  Additional information:
  # lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:  20.04

  # uname -a
  Linux foo.example.com 5.4.0-18-generic #22-Ubuntu SMP Sat Mar 7 18:13:06 UTC 
2020 x86_64 x86_64 x86_64 GNU/Linux

  # apt-cache policy apparmor squid
  apparmor:
Installed: 2.13.3-7ubuntu2
Candidate: 2.13.3-7ubuntu2
Version table:
   *** 2.13.3-7ubuntu2 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status
  squid:
Installed: 4.10-1ubuntu1
Candidate: 4.10-1ubuntu1
Version table:
   *** 4.10-1ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1869024/+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 1872564] [NEW] /proc/sys/kernel/random/boot_id rule missing from abstractions/nameservice

2020-04-13 Thread Simon Déziel
Public bug reported:

# Description

On a default Focal install, systemd is used when looking up passwd and
group information:

# grep systemd /etc/nsswitch.conf 
passwd: files systemd
group:  files systemd

Daemons confined by Apparmor that also query those "databases" will
cause this Apparmor denial:

audit: type=1400 audit(1586825456.411:247): apparmor="DENIED"
operation="open" namespace="root//lxd-fb1_"
profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id"
pid=7370 comm="named" requested_mask="r" denied_mask="r" fsuid=100
ouid=100

Many daemons confined by Apparmor also happen to downgrade their
privileges so they always end up looking up user/group information.

# Steps to reproduce

1) launch a Focal container (named fb1 here)
$ lxc launch images:ubuntu/focal fb1

2) setup apparmor inside the container (already done on official Ubuntu images)
$ lxc exec fb1 -- apt update && lxc exec fb1 -- apt install apparmor -y

3) install bind9
$ lxc exec fb1 -- apt install bind9 -y

4) check kernel logs for DENIED
$ journalctl -o cat -b0 -k | grep 'apparmor="DENIED"' | grep -F 
'profile="/usr/sbin/named"'


Step 4, should not return anything. Because systemd is involved in the 
user/group lookups, it currently returns the following:

audit: type=1400 audit(1586826072.115:266): apparmor="DENIED" operation="open" 
namespace="root//lxd-fb1_" profile="/usr/sbin/named" 
name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" 
requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:267): apparmor="DENIED" operation="open" 
namespace="root//lxd-fb1_" profile="/usr/sbin/named" 
name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" 
requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:268): apparmor="DENIED" operation="open" 
namespace="root//lxd-fb1_" profile="/usr/sbin/named" 
name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" 
requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:269): apparmor="DENIED" operation="open" 
namespace="root//lxd-fb1_" profile="/usr/sbin/named" 
name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" 
requested_mask="r" denied_mask="r" fsuid=100 ouid=100
audit: type=1400 audit(1586826072.115:270): apparmor="DENIED" operation="open" 
namespace="root//lxd-fb1_" profile="/usr/sbin/named" 
name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" 
requested_mask="r" denied_mask="r" fsuid=100 ouid=100


# Workaround

1) remove systemd from nsswitch.conf
$ lxc exec fb1 -- sed -i 's/ systemd$/ # systemd/' /etc/nsswitch.conf
2) restart named
$ lxc exec fb1 -- service named restart
3) notice no more denials in kernel logs

# Additional information

root@fb1:~# apt-cache policy apparmor
apparmor:
  Installed: 2.13.3-7ubuntu4
  Candidate: 2.13.3-7ubuntu4
  Version table:
 *** 2.13.3-7ubuntu4 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status

root@fb1:~# uname -a
Linux fb1 5.3.0-46-generic #38~18.04.1-Ubuntu SMP Tue Mar 31 04:17:56 UTC 2020 
x86_64 x86_64 x86_64 GNU/Linux

root@fb1:~# lsb_release -rd
Description:Ubuntu Focal Fossa (development branch)
Release:20.04

** Affects: apparmor (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1872564

Title:
  /proc/sys/kernel/random/boot_id rule missing from
  abstractions/nameservice

Status in apparmor package in Ubuntu:
  New

Bug description:
  # Description

  On a default Focal install, systemd is used when looking up passwd and
  group information:

  # grep systemd /etc/nsswitch.conf 
  passwd: files systemd
  group:  files systemd

  Daemons confined by Apparmor that also query those "databases" will
  cause this Apparmor denial:

  audit: type=1400 audit(1586825456.411:247): apparmor="DENIED"
  operation="open" namespace="root//lxd-fb1_"
  profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id"
  pid=7370 comm="named" requested_mask="r" denied_mask="r" fsuid=100
  ouid=100

  Many daemons confined by Apparmor also happen to downgrade their
  privileges so they always end up looking up user/group information.

  # Steps to reproduce

  1) launch a Focal container (named fb1 here)
  $ lxc launch images:ubuntu/focal fb1

  2) setup apparmor inside the container (already done on official Ubuntu 
images)
  $ lxc exec fb1 -- apt update && lxc exec fb1 -- apt install apparmor -y

  3) install bind9
  $ lxc exec fb1 -- apt install bind9 -y

  4) check kernel logs for DENIED
  $ journalctl -o cat -b0 -k | grep 'apparmor="DENIED"' | grep -F 
'profile="/usr/sbin/named"'

  
  Step 4, should not return anything. Because systemd is involved in the 
user/group 

Re: [Touch-packages] [Bug 1869024] Re: add support for DynamicUser feature of systemd

2020-04-11 Thread Simon Déziel
On 2020-04-10 1:16 p.m., Jamie Strandboge wrote:
> The abstraction is meant to cover the client, not systemd internal
> specifics. A client simply accessing that DBus API won't need it and a
> client simply accessing those sockets won't need it. It very well might
> be that a profiled application is using some *ctl command from systemd
> that would need it, but in that case said command would need to be added
> to the policy and the boot-id could be added at that time.

I don't know as squid, named and samba (to name a few) generate many
denials trying to read /proc/sys/kernel/random/boot_id. None of those
are explicitly trying to use the DynamicUser feature. Could it be just a
side effect of how nsswitch.conf is setup by default?

$ grep systemd /etc/nsswitch.conf
passwd: files systemd
group:  files systemd

Maybe you'd prefer this to be reported/discussed in a separated LP?

Regards,
Simon

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1869024

Title:
  add support for DynamicUser feature of systemd

Status in snapd:
  In Progress
Status in apparmor package in Ubuntu:
  Fix Released

Bug description:
  systemd offers to create dynamic (and semi-stable) users for services.
  This causes many services using Apparmor profiles to trigger those
  denials (even when they don't use the DynamicUser feature):

  audit: type=1107 audit(1585076282.591:30): pid=621 uid=103
  auid=4294967295 ses=4294967295 msg='apparmor="DENIED"
  operation="dbus_method_call"  bus="system"
  path="/org/freedesktop/systemd1"
  interface="org.freedesktop.systemd1.Manager" member="GetDynamicUsers"
  mask="send" name="org.freedesktop.systemd1" pid=709
  label="/usr/sbin/squid" peer_pid=1 peer_label="unconfined"

  And more recently with systemd 245 this also get shown:

  audit: type=1400 audit(1585139000.628:39): apparmor="DENIED"
  operation="open" profile="/usr/sbin/squid" name="/run/systemd/userdb/"
  pid=769 comm="squid" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

  
  Additional information:
  # lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:  20.04

  # uname -a
  Linux foo.example.com 5.4.0-18-generic #22-Ubuntu SMP Sat Mar 7 18:13:06 UTC 
2020 x86_64 x86_64 x86_64 GNU/Linux

  # apt-cache policy apparmor squid
  apparmor:
Installed: 2.13.3-7ubuntu2
Candidate: 2.13.3-7ubuntu2
Version table:
   *** 2.13.3-7ubuntu2 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status
  squid:
Installed: 4.10-1ubuntu1
Candidate: 4.10-1ubuntu1
Version table:
   *** 4.10-1ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1869024/+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 1869024] Re: add support for DynamicUser feature of systemd

2020-04-09 Thread Simon Déziel
@jdstrand, asked in #systemd about @{PROC}/sys/kernel/random/boot_id and
didn't get much information back. That said,
https://github.com/systemd/systemd/blob/master/docs/RANDOM_SEEDS.md
#systemds-use-of-random-numbers says:

> At various places systemd needs random bytes for temporary file name
generation, UID allocation randomization, and similar.

As such, I believe this should be permitted.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1869024

Title:
  add support for DynamicUser feature of systemd

Status in snapd:
  In Progress
Status in apparmor package in Ubuntu:
  Fix Released

Bug description:
  systemd offers to create dynamic (and semi-stable) users for services.
  This causes many services using Apparmor profiles to trigger those
  denials (even when they don't use the DynamicUser feature):

  audit: type=1107 audit(1585076282.591:30): pid=621 uid=103
  auid=4294967295 ses=4294967295 msg='apparmor="DENIED"
  operation="dbus_method_call"  bus="system"
  path="/org/freedesktop/systemd1"
  interface="org.freedesktop.systemd1.Manager" member="GetDynamicUsers"
  mask="send" name="org.freedesktop.systemd1" pid=709
  label="/usr/sbin/squid" peer_pid=1 peer_label="unconfined"

  And more recently with systemd 245 this also get shown:

  audit: type=1400 audit(1585139000.628:39): apparmor="DENIED"
  operation="open" profile="/usr/sbin/squid" name="/run/systemd/userdb/"
  pid=769 comm="squid" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

  
  Additional information:
  # lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:  20.04

  # uname -a
  Linux foo.example.com 5.4.0-18-generic #22-Ubuntu SMP Sat Mar 7 18:13:06 UTC 
2020 x86_64 x86_64 x86_64 GNU/Linux

  # apt-cache policy apparmor squid
  apparmor:
Installed: 2.13.3-7ubuntu2
Candidate: 2.13.3-7ubuntu2
Version table:
   *** 2.13.3-7ubuntu2 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status
  squid:
Installed: 4.10-1ubuntu1
Candidate: 4.10-1ubuntu1
Version table:
   *** 4.10-1ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1869024/+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 1863919] Re: [regression] lingering pvscan during boot

2020-04-06 Thread Simon Déziel
@narchetic, I did not notice any slowdown during shutdown but those
servers are headless and I didn't time their reboot.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lvm2 in Ubuntu.
https://bugs.launchpad.net/bugs/1863919

Title:
  [regression] lingering pvscan during boot

Status in lvm2 package in Ubuntu:
  Confirmed

Bug description:
  Since lvm2 was updated to 2.02.176-4.1ubuntu3.18.04.2 on Bionic (LP:
  #1854981), we notice that some of our machines have lingering pvscan
  processes apparently running from the initramfs's root that
  persist/never finish/exit.

  On the affected servers, this is visible as there are 2 instances of
  systemd-udevd, one in the init.scope and another in system.slice:

  $ systemd-cgls | cat
  Control group /:
  -.slice
  ├─user.slice
  │ ├─user-501.slice
  │ │ ├─session-7.scope
  │ │ │ ├─12324 sshd: foo [priv]
  │ │ │ ├─12353 sshd: foo@pts/2
  │ │ │ ├─12354 script --quiet --return --command /bin/bash -l /dev/null
  │ │ │ ├─12356 /bin/bash -l
  │ │ │ ├─12375 sudo -i
  │ │ │ └─12385 -bash
  │ │ └─user@501.service
  │ │   └─init.scope
  │ │ ├─12326 /lib/systemd/systemd --user
  │ │ └─12327 (sd-pam)
  │ └─user-500.slice
  │   ├─user@500.service
  │   │ └─init.scope
  │   │   ├─12185 /lib/systemd/systemd --user
  │   │   └─12186 (sd-pam)
  │   └─session-3.scope
  │ ├─12170 sshd: sdeziel [priv]
  │ ├─12254 sshd: sdeziel@pts/0
  │ ├─12255 script --quiet --return --command /bin/bash -l /dev/null
  │ ├─12257 /bin/bash -l
  │ ├─14409 systemd-cgls
  │ └─14410 cat
  ├─init.scope
  │ ├─   1 /sbin/init kaslr nosplash
  │ ├─1451 /lib/systemd/systemd-udevd --daemon --resolve-names=never
  │ ├─1466 /sbin/lvm pvscan --cache --activate ay --major 8 --minor 3
  │ ├─1470 /sbin/lvm pvscan --cache --activate ay --major 8 --minor 2
  │ ├─1481 /sbin/lvm pvscan --cache --activate ay --major 253 --minor 1
  │ └─1551 /sbin/lvm pvscan --cache --activate ay --major 253 --minor 1
  └─system.slice
├─irqbalance.service
│ └─2796 /usr/sbin/irqbalance --foreground
├─systemd-networkd.service
│ └─2833 /lib/systemd/systemd-networkd
├─systemd-udevd.service
│ └─1627 /lib/systemd/systemd-udevd
├─cron.service
│ ├─ 2786 /usr/sbin/cron -f
│ └─12308 /usr/bin/python /usr/sbin/ganeti-noded -b 172.20.30.212
├─system-serial\x2dgetty.slice
│ └─serial-getty@ttyS0.service
│   └─12112 /sbin/agetty -o -p -- \u --keep-baud 115200,38400,9600 ttyS0 
vt220
├─systemd-journald.service
│ └─1601 /lib/systemd/systemd-journald
├─ssh.service
│ └─12115 /usr/sbin/sshd -D
├─rsyslog.service
│ └─2781 /usr/sbin/rsyslogd -n
├─nagios-nrpe-server.service
│ └─12108 /usr/sbin/nrpe -c /etc/nagios/nrpe.cfg -f
├─lvm2-lvmetad.service
│ └─1630 /sbin/lvmetad -f
├─systemd-resolved.service
│ └─3280 /lib/systemd/systemd-resolved
├─dbus.service
│ └─2762 /usr/bin/dbus-daemon --system --address=systemd: --nofork 
--nopidf...
├─systemd-timesyncd.service
│ └─2491 /lib/systemd/systemd-timesyncd
├─system-getty.slice
│ └─getty@tty1.service
│   └─12113 /sbin/agetty -o -p -- \u --noclear tty1 linux
├─systemd-logind.service
│ └─2797 /lib/systemd/systemd-logind
└─ganeti.service
  ├─ 3892 /usr/sbin/ganeti-confd
  ├─12173 /usr/sbin/ganeti-kvmd
  └─12276 /usr/sbin/ganeti-mond

  The systemd-udevd in init.scope and the many /sbin/lvm pvscan it
  launched during boot are left there forever.

  This trips our monitoring for binaries using deleted binaries/libs and
  is also visible like that:

  # pgrep systemd-udevd
  1451
  1627

  # ls -l /proc/1451/exe
  lrwxrwxrwx 1 root root 0 Feb 19 10:35 /proc/1451/exe -> 
'/lib/systemd/systemd-udevd (deleted)'

  # ls -l /proc/1627/exe
  lrwxrwxrwx 1 root root 0 Feb 19 10:35 /proc/1627/exe -> 
/lib/systemd/systemd-udevd

  
  This can be compared with another server *NOT AFFECTED*, where the init.scope 
is cleaner (/sbin/init only) and a single systemd-udevd process:

  # systemd-cgls | cat
  Control group /:
  -.slice
  ├─user.slice
  │ └─user-0.slice
  │   ├─session-313.scope
  │   │ ├─90332 sshd: root@pts/0
  │   │ ├─90406 script --quiet --return --command /bin/bash -l /dev/null
  │   │ ├─90410 /bin/bash -l
  │   │ ├─90436 systemd-cgls
  │   │ └─90437 cat
  │   └─user@0.service
  │ └─init.scope
  │   ├─90334 /lib/systemd/systemd --user
  │   └─90335 (sd-pam)
  ├─init.scope
  │ └─1 /sbin/init kaslr nosplash
  └─system.slice
  ...
├─systemd-udevd.service
│ └─2622 /lib/systemd/systemd-udevd
  ...
├─lvm2-lvmetad.service
│ └─2621 /sbin/lvmetad -f
  ...

  
  Additional information:

  # lsb_release -rd
  Description:  Ubuntu 18.04.4 LTS
  Release:  18.04
  # apt-cache policy lvm2 systemd
  lvm2:
Installed: 2.02.176-4.1ubuntu3.18.04.2
Candidate: 2.02.176-4.1ubuntu3.18.04.2
Version table:
   *** 2.02.176-4.1ubuntu3.18.04.2 500
  

[Touch-packages] [Bug 1869024] Re: add support for DynamicUser feature of systemd

2020-03-25 Thread Simon Déziel
As mentioned in LP: #1796911 by xnox, some abstractions should be
augmented with the corresponding dbus rules. Support for userdb should
also be added IMHO.

Here are the rules that were needed in my tests on an up to date Focal:

  # systemd DynamicUser
  /run/systemd/userdb/ r,
  /run/systemd/userdb/io.systemd.DynamicUser rw,
  @{PROC}/sys/kernel/random/boot_id r,
  #include 
  dbus send
 bus=system
 path="/org/freedesktop/systemd1"
 interface="org.freedesktop.systemd1.Manager"
 member="{GetDynamicUsers,LookupDynamicUserByName,LookupDynamicUserByUID}"
 peer=(name=("org.freedesktop.systemd1")),


The boot_id is a concern for privacy/tracking abuse so I also tried denying it 
and it doesn't seem to cause visible problems.

** Description changed:

  systemd offers to create dynamic (and semi-stable) users for services.
  This causes many services using Apparmor profiles to trigger those
  denials (even when they don't use the DynamicUser feature):
  
  audit: type=1107 audit(1585076282.591:30): pid=621 uid=103
  auid=4294967295 ses=4294967295 msg='apparmor="DENIED"
  operation="dbus_method_call"  bus="system"
  path="/org/freedesktop/systemd1"
  interface="org.freedesktop.systemd1.Manager" member="GetDynamicUsers"
  mask="send" name="org.freedesktop.systemd1" pid=709
  label="/usr/sbin/squid" peer_pid=1 peer_label="unconfined"
  
  And more recently with systemd 245 this also get shown:
  
  audit: type=1400 audit(1585139000.628:39): apparmor="DENIED"
  operation="open" profile="/usr/sbin/squid" name="/run/systemd/userdb/"
  pid=769 comm="squid" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
+ 
+ 
+ Additional information:
+ # lsb_release -rd
+ Description:  Ubuntu Focal Fossa (development branch)
+ Release:  20.04
+ 
+ # uname -a
+ Linux foo.example.com 5.4.0-18-generic #22-Ubuntu SMP Sat Mar 7 18:13:06 UTC 
2020 x86_64 x86_64 x86_64 GNU/Linux
+ 
+ # apt-cache policy apparmor squid
+ apparmor:
+   Installed: 2.13.3-7ubuntu2
+   Candidate: 2.13.3-7ubuntu2
+   Version table:
+  *** 2.13.3-7ubuntu2 500
+ 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
+ 100 /var/lib/dpkg/status
+ squid:
+   Installed: 4.10-1ubuntu1
+   Candidate: 4.10-1ubuntu1
+   Version table:
+  *** 4.10-1ubuntu1 500
+ 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
+ 100 /var/lib/dpkg/status

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1869024

Title:
  add support for DynamicUser feature of systemd

Status in apparmor package in Ubuntu:
  New

Bug description:
  systemd offers to create dynamic (and semi-stable) users for services.
  This causes many services using Apparmor profiles to trigger those
  denials (even when they don't use the DynamicUser feature):

  audit: type=1107 audit(1585076282.591:30): pid=621 uid=103
  auid=4294967295 ses=4294967295 msg='apparmor="DENIED"
  operation="dbus_method_call"  bus="system"
  path="/org/freedesktop/systemd1"
  interface="org.freedesktop.systemd1.Manager" member="GetDynamicUsers"
  mask="send" name="org.freedesktop.systemd1" pid=709
  label="/usr/sbin/squid" peer_pid=1 peer_label="unconfined"

  And more recently with systemd 245 this also get shown:

  audit: type=1400 audit(1585139000.628:39): apparmor="DENIED"
  operation="open" profile="/usr/sbin/squid" name="/run/systemd/userdb/"
  pid=769 comm="squid" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

  
  Additional information:
  # lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:  20.04

  # uname -a
  Linux foo.example.com 5.4.0-18-generic #22-Ubuntu SMP Sat Mar 7 18:13:06 UTC 
2020 x86_64 x86_64 x86_64 GNU/Linux

  # apt-cache policy apparmor squid
  apparmor:
Installed: 2.13.3-7ubuntu2
Candidate: 2.13.3-7ubuntu2
Version table:
   *** 2.13.3-7ubuntu2 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status
  squid:
Installed: 4.10-1ubuntu1
Candidate: 4.10-1ubuntu1
Version table:
   *** 4.10-1ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1869024/+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 1869024] [NEW] add support for DynamicUser feature of systemd

2020-03-25 Thread Simon Déziel
Public bug reported:

systemd offers to create dynamic (and semi-stable) users for services.
This causes many services using Apparmor profiles to trigger those
denials (even when they don't use the DynamicUser feature):

audit: type=1107 audit(1585076282.591:30): pid=621 uid=103
auid=4294967295 ses=4294967295 msg='apparmor="DENIED"
operation="dbus_method_call"  bus="system"
path="/org/freedesktop/systemd1"
interface="org.freedesktop.systemd1.Manager" member="GetDynamicUsers"
mask="send" name="org.freedesktop.systemd1" pid=709
label="/usr/sbin/squid" peer_pid=1 peer_label="unconfined"

And more recently with systemd 245 this also get shown:

audit: type=1400 audit(1585139000.628:39): apparmor="DENIED"
operation="open" profile="/usr/sbin/squid" name="/run/systemd/userdb/"
pid=769 comm="squid" requested_mask="r" denied_mask="r" fsuid=0 ouid=0


Additional information:
# lsb_release -rd
Description:Ubuntu Focal Fossa (development branch)
Release:20.04

# uname -a
Linux foo.example.com 5.4.0-18-generic #22-Ubuntu SMP Sat Mar 7 18:13:06 UTC 
2020 x86_64 x86_64 x86_64 GNU/Linux

# apt-cache policy apparmor squid
apparmor:
  Installed: 2.13.3-7ubuntu2
  Candidate: 2.13.3-7ubuntu2
  Version table:
 *** 2.13.3-7ubuntu2 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status
squid:
  Installed: 4.10-1ubuntu1
  Candidate: 4.10-1ubuntu1
  Version table:
 *** 4.10-1ubuntu1 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status

** Affects: apparmor (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1869024

Title:
  add support for DynamicUser feature of systemd

Status in apparmor package in Ubuntu:
  New

Bug description:
  systemd offers to create dynamic (and semi-stable) users for services.
  This causes many services using Apparmor profiles to trigger those
  denials (even when they don't use the DynamicUser feature):

  audit: type=1107 audit(1585076282.591:30): pid=621 uid=103
  auid=4294967295 ses=4294967295 msg='apparmor="DENIED"
  operation="dbus_method_call"  bus="system"
  path="/org/freedesktop/systemd1"
  interface="org.freedesktop.systemd1.Manager" member="GetDynamicUsers"
  mask="send" name="org.freedesktop.systemd1" pid=709
  label="/usr/sbin/squid" peer_pid=1 peer_label="unconfined"

  And more recently with systemd 245 this also get shown:

  audit: type=1400 audit(1585139000.628:39): apparmor="DENIED"
  operation="open" profile="/usr/sbin/squid" name="/run/systemd/userdb/"
  pid=769 comm="squid" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

  
  Additional information:
  # lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:  20.04

  # uname -a
  Linux foo.example.com 5.4.0-18-generic #22-Ubuntu SMP Sat Mar 7 18:13:06 UTC 
2020 x86_64 x86_64 x86_64 GNU/Linux

  # apt-cache policy apparmor squid
  apparmor:
Installed: 2.13.3-7ubuntu2
Candidate: 2.13.3-7ubuntu2
Version table:
   *** 2.13.3-7ubuntu2 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status
  squid:
Installed: 4.10-1ubuntu1
Candidate: 4.10-1ubuntu1
Version table:
   *** 4.10-1ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1869024/+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 1867488] Re: APT::Sandbox::Seccomp prevents connect, sendto, socket syscalls on Focal

2020-03-24 Thread Simon Déziel
I'm happy to report that apt version 2.0.0 fixed this bug, thanks!

$ apt-cache policy apt
apt:
  Installed: 2.0.0
  Candidate: 2.0.0
  Version table:
 *** 2.0.0 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status

** Changed in: apt (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1867488

Title:
  APT::Sandbox::Seccomp prevents connect,sendto,socket syscalls on Focal

Status in apt package in Ubuntu:
  Fix Released

Bug description:
  # Steps to reproduce:

  $ lxc launch images:ubuntu/focal fa1
  $ lxc shell fa1
  root@fa1:~# echo 'APT::Sandbox::Seccomp "true";' > 
/etc/apt/apt.conf.d/01apt-seccomp
  root@fa1:~# rm /var/lib/apt/lists/*Release   # makes sure we fetch stuff from 
the network
  root@fa1:~# apt-get update
  Hit:1 http://security.ubuntu.com/ubuntu focal-security InRelease
  Get:2 http://archive.ubuntu.com/ubuntu focal InRelease [255 kB]
  Hit:3 http://archive.ubuntu.com/ubuntu focal-updates InRelease
  Get:4 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages [976 kB]
  Get:5 http://archive.ubuntu.com/ubuntu focal/universe amd64 Packages [8,623 
kB]
  30% [4 Packages store 0 B] [5 Packages 100 kB/8,623 kB 1%]
    Seccomp prevented execution of syscall 41 on architecture amd64 

  Reading package lists... Done
  E: Method store has died unexpectedly!
  E: Sub-process store returned an error code (31)

  This was tested in a container as well as inside a VM, same issue.
  This used to work with Bionic.

  # Workaround

  Fortunately, apt supports manual whitelisting of syscalls. A
  workaround is to allow 3 more syscalls.

  root@fa1:~# echo 'APT::Sandbox::Seccomp::Allow
  "connect,sendto,socket";' >> /etc/apt/apt.conf.d/01apt-seccomp

  # Additional information

  root@fa1:~# lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:  20.04

  root@fa1:~# uname -a
  Linux fa1 5.3.0-40-generic #32~18.04.1-Ubuntu SMP Mon Feb 3 14:05:59 UTC 2020 
x86_64 x86_64 x86_64 GNU/Linux

  root@fa1:~# apt-cache policy apt libc-bin
  apt:
    Installed: 1.9.10
    Candidate: 1.9.10
    Version table:
   *** 1.9.10 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status
  libc-bin:
    Installed: 2.31-0ubuntu5
    Candidate: 2.31-0ubuntu5
    Version table:
   *** 2.31-0ubuntu5 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1867488/+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 1868276] [NEW] Libgcrypt warning: missing initialization - please fix the application

2020-03-20 Thread Simon Déziel
Public bug reported:

In Focal, running 'apt update' result in the following messages being
logged:

Mar 20 15:24:12 fa1 http[3392]: Libgcrypt warning: missing initialization - 
please fix the application
Mar 20 15:24:12 fa1 http[3393]: Libgcrypt warning: missing initialization - 
please fix the application
Mar 20 15:24:13 fa1 store[3550]: Libgcrypt warning: missing initialization - 
please fix the application

# Steps to reproduce

$ lxc launch images:ubuntu/focal fa1
$ lxc shell fa1
root@fa1:~# rm /var/lib/apt/lists/*InRelease  # make sure we pull from the 
network
root@fa1:~# apt update
root@fa1:~# journalctl -b0 | grep -i Libgcrypt
Mar 20 15:24:12 fa1 http[3392]: Libgcrypt warning: missing initialization - 
please fix the application
Mar 20 15:24:12 fa1 http[3393]: Libgcrypt warning: missing initialization - 
please fix the application
Mar 20 15:24:13 fa1 store[3550]: Libgcrypt warning: missing initialization - 
please fix the application


# Additional information
root@fa1:~# lsb_release -rd
Description:Ubuntu Focal Fossa (development branch)
Release:20.04
root@fa1:~# apt-cache policy apt
apt:
  Installed: 1.9.10
  Candidate: 1.9.10
  Version table:
 *** 1.9.10 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status

** Affects: apt (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1868276

Title:
  Libgcrypt warning: missing initialization - please fix the application

Status in apt package in Ubuntu:
  New

Bug description:
  In Focal, running 'apt update' result in the following messages being
  logged:

  Mar 20 15:24:12 fa1 http[3392]: Libgcrypt warning: missing initialization - 
please fix the application
  Mar 20 15:24:12 fa1 http[3393]: Libgcrypt warning: missing initialization - 
please fix the application
  Mar 20 15:24:13 fa1 store[3550]: Libgcrypt warning: missing initialization - 
please fix the application

  # Steps to reproduce

  $ lxc launch images:ubuntu/focal fa1
  $ lxc shell fa1
  root@fa1:~# rm /var/lib/apt/lists/*InRelease  # make sure we pull from the 
network
  root@fa1:~# apt update
  root@fa1:~# journalctl -b0 | grep -i Libgcrypt
  Mar 20 15:24:12 fa1 http[3392]: Libgcrypt warning: missing initialization - 
please fix the application
  Mar 20 15:24:12 fa1 http[3393]: Libgcrypt warning: missing initialization - 
please fix the application
  Mar 20 15:24:13 fa1 store[3550]: Libgcrypt warning: missing initialization - 
please fix the application

  
  # Additional information
  root@fa1:~# lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:  20.04
  root@fa1:~# apt-cache policy apt
  apt:
Installed: 1.9.10
Candidate: 1.9.10
Version table:
   *** 1.9.10 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1868276/+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 1867488] [NEW] APT::Sandbox::Seccomp prevents connect, sendto, socket syscalls on Focal

2020-03-14 Thread Simon Déziel
Public bug reported:

# Steps to reproduce:

$ lxc launch images:ubuntu/focal fa1
$ lxc shell fa1
root@fa1:~# echo 'APT::Sandbox::Seccomp "true";' > 
/etc/apt/apt.conf.d/01apt-seccomp
root@fa1:~# rm /var/lib/apt/lists/*Release   # makes sure we fetch stuff from 
the network
root@fa1:~# apt-get update
Hit:1 http://security.ubuntu.com/ubuntu focal-security InRelease
Get:2 http://archive.ubuntu.com/ubuntu focal InRelease [255 kB]
Hit:3 http://archive.ubuntu.com/ubuntu focal-updates InRelease
Get:4 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages [976 kB]
Get:5 http://archive.ubuntu.com/ubuntu focal/universe amd64 Packages [8,623 kB]
30% [4 Packages store 0 B] [5 Packages 100 kB/8,623 kB 1%]
  Seccomp prevented execution of syscall 41 on architecture amd64 

Reading package lists... Done
E: Method store has died unexpectedly!
E: Sub-process store returned an error code (31)

This was tested in a container as well as inside a VM, same issue. This
used to work with Bionic.

# Workaround

Fortunately, apt supports manual whitelisting of syscalls. A workaround
is to allow 3 more syscalls.

root@fa1:~# echo 'APT::Sandbox::Seccomp::Allow "connect,sendto,socket";'
>> /etc/apt/apt.conf.d/01apt-seccomp

# Additional information

root@fa1:~# lsb_release -rd
Description:Ubuntu Focal Fossa (development branch)
Release:20.04

root@fa1:~# uname -a
Linux fa1 5.3.0-40-generic #32~18.04.1-Ubuntu SMP Mon Feb 3 14:05:59 UTC 2020 
x86_64 x86_64 x86_64 GNU/Linux

root@fa1:~# apt-cache policy apt libc-bin
apt:
  Installed: 1.9.10
  Candidate: 1.9.10
  Version table:
 *** 1.9.10 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status
libc-bin:
  Installed: 2.31-0ubuntu5
  Candidate: 2.31-0ubuntu5
  Version table:
 *** 2.31-0ubuntu5 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status

** Affects: apt (Ubuntu)
 Importance: Undecided
 Status: New

** Description changed:

  # Steps to reproduce:
  
  $ lxc launch images:ubuntu/focal fa1
  $ lxc shell fa1
  root@fa1:~# echo 'APT::Sandbox::Seccomp "true";' > 
/etc/apt/apt.conf.d/01apt-seccomp
  root@fa1:~# rm /var/lib/apt/lists/*Release   # makes sure we fetch stuff from 
the network
  root@fa1:~# apt-get update
  Hit:1 http://security.ubuntu.com/ubuntu focal-security InRelease
  Get:2 http://archive.ubuntu.com/ubuntu focal InRelease [255 kB]
  Hit:3 http://archive.ubuntu.com/ubuntu focal-updates InRelease
  Get:4 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages [976 kB]
  Get:5 http://archive.ubuntu.com/ubuntu focal/universe amd64 Packages [8,623 
kB]
  30% [4 Packages store 0 B] [5 Packages 100 kB/8,623 kB 1%]
-   Seccomp prevented execution of syscall 41 on architecture amd64 

- Reading package lists... Done 
+   Seccomp prevented execution of syscall 41 on architecture amd64 

+ Reading package lists... Done
  E: Method store has died unexpectedly!
  E: Sub-process store returned an error code (31)
  
  This was tested in a container as well as inside a VM, same issue. This
  used to work with Bionic.
  
- 
  # Workaround
  
  Fortunately, apt supports manual whitelisting of syscalls. A workaround
- is to allow the socket and connect syscalls as simply allowing socket
- fails with:
+ is to allow 3 more syscalls.
  
-   Seccomp prevented execution of syscall 42 on architecture
- amd64 
- 
- root@fa1:~# echo 'APT::Sandbox::Seccomp::Allow "socket,connect";' >>
- /etc/apt/apt.conf.d/01apt-seccomp
- 
+ root@fa1:~# echo 'APT::Sandbox::Seccomp::Allow "connect,sendto,socket";'
+ >> /etc/apt/apt.conf.d/01apt-seccomp
  
  # Additional information
  
  root@fa1:~# lsb_release -rd
  Description:  Ubuntu Focal Fossa (development branch)
  Release:  20.04
  
  root@fa1:~# uname -a
  Linux fa1 5.3.0-40-generic #32~18.04.1-Ubuntu SMP Mon Feb 3 14:05:59 UTC 2020 
x86_64 x86_64 x86_64 GNU/Linux
  
  root@fa1:~# apt-cache policy apt libc-bin
  apt:
-   Installed: 1.9.10
-   Candidate: 1.9.10
-   Version table:
-  *** 1.9.10 500
- 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
- 100 /var/lib/dpkg/status
+   Installed: 1.9.10
+   Candidate: 1.9.10
+   Version table:
+  *** 1.9.10 500
+ 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
+ 100 /var/lib/dpkg/status
  libc-bin:
-   Installed: 2.31-0ubuntu5
-   Candidate: 2.31-0ubuntu5
-   Version table:
-  *** 2.31-0ubuntu5 500
- 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
- 100 /var/lib/dpkg/status
+   Installed: 2.31-0ubuntu5
+   Candidate: 2.31-0ubuntu5
+   Version table:
+  *** 2.31-0ubuntu5 500
+ 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
+ 100 /var/lib/dpkg/status

** Summary changed:

- APT::Sandbox::Seccomp prevents socket syscall on Focal
+ APT::Sandbox::Seccomp prevents 

[Touch-packages] [Bug 1863919] [NEW] [regression] lingering pvscan during boot

2020-02-19 Thread Simon Déziel
Public bug reported:

Since lvm2 was updated to 2.02.176-4.1ubuntu3.18.04.2 on Bionic (LP:
#1854981), we notice that some of our machines have lingering pvscan
processes apparently running from the initramfs's root that
persist/never finish/exit.

On the affected servers, this is visible as there are 2 instances of
systemd-udevd, one in the init.scope and another in system.slice:

$ systemd-cgls | cat
Control group /:
-.slice
├─user.slice
│ ├─user-501.slice
│ │ ├─session-7.scope
│ │ │ ├─12324 sshd: foo [priv]
│ │ │ ├─12353 sshd: foo@pts/2
│ │ │ ├─12354 script --quiet --return --command /bin/bash -l /dev/null
│ │ │ ├─12356 /bin/bash -l
│ │ │ ├─12375 sudo -i
│ │ │ └─12385 -bash
│ │ └─user@501.service
│ │   └─init.scope
│ │ ├─12326 /lib/systemd/systemd --user
│ │ └─12327 (sd-pam)
│ └─user-500.slice
│   ├─user@500.service
│   │ └─init.scope
│   │   ├─12185 /lib/systemd/systemd --user
│   │   └─12186 (sd-pam)
│   └─session-3.scope
│ ├─12170 sshd: sdeziel [priv]
│ ├─12254 sshd: sdeziel@pts/0
│ ├─12255 script --quiet --return --command /bin/bash -l /dev/null
│ ├─12257 /bin/bash -l
│ ├─14409 systemd-cgls
│ └─14410 cat
├─init.scope
│ ├─   1 /sbin/init kaslr nosplash
│ ├─1451 /lib/systemd/systemd-udevd --daemon --resolve-names=never
│ ├─1466 /sbin/lvm pvscan --cache --activate ay --major 8 --minor 3
│ ├─1470 /sbin/lvm pvscan --cache --activate ay --major 8 --minor 2
│ ├─1481 /sbin/lvm pvscan --cache --activate ay --major 253 --minor 1
│ └─1551 /sbin/lvm pvscan --cache --activate ay --major 253 --minor 1
└─system.slice
  ├─irqbalance.service
  │ └─2796 /usr/sbin/irqbalance --foreground
  ├─systemd-networkd.service
  │ └─2833 /lib/systemd/systemd-networkd
  ├─systemd-udevd.service
  │ └─1627 /lib/systemd/systemd-udevd
  ├─cron.service
  │ ├─ 2786 /usr/sbin/cron -f
  │ └─12308 /usr/bin/python /usr/sbin/ganeti-noded -b 172.20.30.212
  ├─system-serial\x2dgetty.slice
  │ └─serial-getty@ttyS0.service
  │   └─12112 /sbin/agetty -o -p -- \u --keep-baud 115200,38400,9600 ttyS0 vt220
  ├─systemd-journald.service
  │ └─1601 /lib/systemd/systemd-journald
  ├─ssh.service
  │ └─12115 /usr/sbin/sshd -D
  ├─rsyslog.service
  │ └─2781 /usr/sbin/rsyslogd -n
  ├─nagios-nrpe-server.service
  │ └─12108 /usr/sbin/nrpe -c /etc/nagios/nrpe.cfg -f
  ├─lvm2-lvmetad.service
  │ └─1630 /sbin/lvmetad -f
  ├─systemd-resolved.service
  │ └─3280 /lib/systemd/systemd-resolved
  ├─dbus.service
  │ └─2762 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidf...
  ├─systemd-timesyncd.service
  │ └─2491 /lib/systemd/systemd-timesyncd
  ├─system-getty.slice
  │ └─getty@tty1.service
  │   └─12113 /sbin/agetty -o -p -- \u --noclear tty1 linux
  ├─systemd-logind.service
  │ └─2797 /lib/systemd/systemd-logind
  └─ganeti.service
├─ 3892 /usr/sbin/ganeti-confd
├─12173 /usr/sbin/ganeti-kvmd
└─12276 /usr/sbin/ganeti-mond

The systemd-udevd in init.scope and the many /sbin/lvm pvscan it
launched during boot are left there forever.

This trips our monitoring for binaries using deleted binaries/libs and
is also visible like that:

# pgrep systemd-udevd
1451
1627

# ls -l /proc/1451/exe
lrwxrwxrwx 1 root root 0 Feb 19 10:35 /proc/1451/exe -> 
'/lib/systemd/systemd-udevd (deleted)'

# ls -l /proc/1627/exe
lrwxrwxrwx 1 root root 0 Feb 19 10:35 /proc/1627/exe -> 
/lib/systemd/systemd-udevd


This can be compared with another server *NOT AFFECTED*, where the init.scope 
is cleaner (/sbin/init only) and a single systemd-udevd process:

# systemd-cgls | cat
Control group /:
-.slice
├─user.slice
│ └─user-0.slice
│   ├─session-313.scope
│   │ ├─90332 sshd: root@pts/0
│   │ ├─90406 script --quiet --return --command /bin/bash -l /dev/null
│   │ ├─90410 /bin/bash -l
│   │ ├─90436 systemd-cgls
│   │ └─90437 cat
│   └─user@0.service
│ └─init.scope
│   ├─90334 /lib/systemd/systemd --user
│   └─90335 (sd-pam)
├─init.scope
│ └─1 /sbin/init kaslr nosplash
└─system.slice
...
  ├─systemd-udevd.service
  │ └─2622 /lib/systemd/systemd-udevd
...
  ├─lvm2-lvmetad.service
  │ └─2621 /sbin/lvmetad -f
...


Additional information:

# lsb_release -rd
Description:Ubuntu 18.04.4 LTS
Release:18.04
# apt-cache policy lvm2 systemd
lvm2:
  Installed: 2.02.176-4.1ubuntu3.18.04.2
  Candidate: 2.02.176-4.1ubuntu3.18.04.2
  Version table:
 *** 2.02.176-4.1ubuntu3.18.04.2 500
500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
100 /var/lib/dpkg/status
 2.02.176-4.1ubuntu3 500
500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages
systemd:
  Installed: 237-3ubuntu10.39
  Candidate: 237-3ubuntu10.39
  Version table:
 *** 237-3ubuntu10.39 500
500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
100 /var/lib/dpkg/status
 237-3ubuntu10.38 500
500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 
Packages
 237-3ubuntu10 500
500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages

** Affects: 

[Touch-packages] [Bug 1827253] Re: [apparmor] missing 'mr' on binary for usage on containers

2020-02-14 Thread Simon Déziel
The version in focal-proposed works well, thanks Christian! I hadn't
anticipated the additional roadblocks so I really appreciate you pushing
it forward nevertheless!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1827253

Title:
  [apparmor] missing 'mr' on binary for usage on containers

Status in rsyslog package in Ubuntu:
  Fix Released
Status in rsyslog source package in Bionic:
  Triaged
Status in rsyslog source package in Disco:
  Triaged
Status in rsyslog source package in Eoan:
  Triaged

Bug description:
  [Impact]

   * rsyslog ships with a (Default disable) apparmor profile.
   * Security sensitive users are in general encouraged to enable such
     profiles but unfortunately due to slightly new behavior of the program
     the profile prevents its usage.
   * Allow the program to map/read its binary to get this working again

  [Test Case]

  1) Create a 'eoan' container called rs1 here:
    lxc launch ubuntu-daily:e rs1
  2) Enter the container
    lxc shell rs1
  3) Enable apparmor profile
    rm /etc/apparmor.d/disable/usr.sbin.rsyslogd
    apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
    systemctl restart rsyslog
  4) notice rsyslog failed to start
    systemctl status rsyslog

  [Regression Potential]

   * This is just opening up the apparmor profile a bit. Therefore the only
     regression it could cause IMHO is a security issue. But then what it
     actually allows is reading (not writing!) its own binary which should
     be very safe.
   * Thinking further it came to my mind that package updates (independent 
 to the change) might restart services and that means if there is any 
 issue e.g. in a local config that worked but now fails (not by this 
 change but in general) then the upgrade will not cause, but trigger 
 this. This is a general regression risk for any upload, but in this 
 case worth to mention as it is about log handling - which if broken - 
 makes large scale systems hard to debug.

  [Other Info]

   * n/a

  ---

  Issue description:

  Enabling the rsyslog (disabled by default) Apparmor profile causes
  rsyslog to fail to start when running *inside a container*.

  Steps to reproduce:

  1) Create a 'eoan' container called rs1 here:
    lxc launch ubuntu-daily:e rs1
  2) Enter the container
    lxc shell rs1
  3) Enable apparmor profile
    rm /etc/apparmor.d/disable/usr.sbin.rsyslogd
    apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
    systemctl restart rsyslog
  4) notice rsyslog failed to start
    systemctl status rsyslog

  Workaround:

    echo '  /usr/sbin/rsyslogd mr,' >> /etc/apparmor.d/local/usr.sbin.rsyslogd
    apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
    systemctl restart rsyslog

  Additional information:

  root@rs1:~# uname -a
  Linux rs1 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 
x86_64 x86_64 GNU/Linux
  root@rs1:~# lsb_release -rd
  Description:  Ubuntu Eoan EANIMAL (development branch)
  Release:  19.10
  root@rs1:~# dpkg -l| grep -wE 'apparmor|rsyslog'
  ii  apparmor 2.13.2-9ubuntu6  amd64user-space parser utility for 
AppArmor
  ii  rsyslog  8.32.0-1ubuntu7  amd64reliable system and kernel logging 
daemon

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: rsyslog 8.32.0-1ubuntu7
  ProcVersionSignature: Ubuntu 4.15.0-48.51-generic 4.15.18
  Uname: Linux 4.15.0-48-generic x86_64
  ApportVersion: 2.20.10-0ubuntu27
  Architecture: amd64
  Date: Wed May  1 17:36:29 2019
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: rsyslog
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1827253/+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


Re: [Touch-packages] [Bug 1718227] Re: replacement of ifupdown with netplan needs integration for /etc/network/if{up, down}.d scripts

2019-12-15 Thread Simon Déziel
On 2019-12-11 12:33 p.m., Rafael David Tinoco wrote:
> For openvpn + systemd-resolve:
> 
> With "up / down" openvpn config file commands you can wrap "systemd-
> resolve --set-dns=XXX" and update the given DNS servers.

There's a package for that: openvpn-systemd-resolved

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to avahi in Ubuntu.
https://bugs.launchpad.net/bugs/1718227

Title:
  replacement of ifupdown with netplan needs integration for
  /etc/network/if{up,down}.d scripts

Status in aiccu package in Ubuntu:
  Invalid
Status in aoetools package in Ubuntu:
  New
Status in avahi package in Ubuntu:
  New
Status in bind9 package in Ubuntu:
  Invalid
Status in chrony package in Ubuntu:
  Fix Released
Status in clamav package in Ubuntu:
  Triaged
Status in controlaula package in Ubuntu:
  Invalid
Status in ethtool package in Ubuntu:
  Triaged
Status in guidedog package in Ubuntu:
  New
Status in htpdate package in Ubuntu:
  New
Status in ifenslave package in Ubuntu:
  Won't Fix
Status in ifmetric package in Ubuntu:
  Won't Fix
Status in ifupdown-multi package in Ubuntu:
  New
Status in ifupdown-scripts-zg2 package in Ubuntu:
  Invalid
Status in isatapd package in Ubuntu:
  New
Status in lprng package in Ubuntu:
  New
Status in miredo package in Ubuntu:
  New
Status in mythtv package in Ubuntu:
  New
Status in nplan package in Ubuntu:
  New
Status in nss-pam-ldapd package in Ubuntu:
  New
Status in ntp package in Ubuntu:
  Won't Fix
Status in openntpd package in Ubuntu:
  New
Status in openresolv package in Ubuntu:
  Won't Fix
Status in openssh package in Ubuntu:
  Fix Released
Status in openvpn package in Ubuntu:
  Confirmed
Status in openvswitch package in Ubuntu:
  Triaged
Status in postfix package in Ubuntu:
  New
Status in quicktun package in Ubuntu:
  New
Status in resolvconf package in Ubuntu:
  New
Status in sendmail package in Ubuntu:
  New
Status in shorewall-init package in Ubuntu:
  New
Status in sidedoor package in Ubuntu:
  New
Status in slrn package in Ubuntu:
  New
Status in tinc package in Ubuntu:
  New
Status in ubuntu-fan package in Ubuntu:
  Fix Released
Status in ucarp package in Ubuntu:
  New
Status in uml-utilities package in Ubuntu:
  New
Status in uruk package in Ubuntu:
  New
Status in vlan package in Ubuntu:
  Won't Fix
Status in vzctl package in Ubuntu:
  Triaged
Status in wide-dhcpv6 package in Ubuntu:
  New
Status in wpa package in Ubuntu:
  New

Bug description:
  when network is configured with ifupdown, scripts in
  /etc/network/ifup.d/ were called on network being brought up and
  /etc/network/ifdown.d were called on network being brought down.

  Any packages that shipped these hooks need to be verified to have the
  same functionality under a netplan configured system.

  # binpkgs=$(apt-file search /etc/network/if-up | sed 's,: .*,,' | sort -u)
  # for i in $binpkgs; do
src=$(apt-cache show $i | awk '$1 == "Source:" { print $2; exit(0); }');
[ -z "$src" ] && src="$i"; echo $src; done | sort -u

  aiccu
  aoetools
  avahi
  bind9
  chrony
  clamav
  controlaula
  epoptes
  ethtool
  guidedog
  htpdate
  ifenslave
  ifmetric
  ifupdown-extra
  ifupdown-multi
  ifupdown-scripts-zg2
  isatapd
  lprng
  miredo
  mythtv-backend
  nss-pam-ldapd
  ntp
  openntpd
  openresolv
  openssh
  openvpn
  postfix
  quicktun
  resolvconf
  sendmail
  shorewall-init
  sidedoor
  slrn
  tinc
  ubuntu-fan
  ucarp
  uml-utilities
  uruk
  vlan
  vzctl
  wide-dhcpv6
  wpa

  
  Related bugs:
   * bug 1718227: replacement of ifupdown with netplan needs integration for 
/etc/network/if{up,down}.d scripts 
   * bug 1713803: replacement of resolvconf with systemd needs integration 
   * bug 1717983: replacement of isc-dhcp-client with with systemd-networkd for 
dhclient needs integration

  
  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: netplan (not installed)
  ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5
  Uname: Linux 4.12.0-11-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Tue Sep 19 10:53:08 2017
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (789 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: plan
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1718227/+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


Re: [Touch-packages] [Bug 1718227] Re: replacement of ifupdown with netplan needs integration for /etc/network/if{up, down}.d scripts

2019-12-15 Thread Simon Déziel
On 2019-12-11 12:33 p.m., Rafael David Tinoco wrote:
> For openvpn + systemd-resolve:
> 
> With "up / down" openvpn config file commands you can wrap "systemd-
> resolve --set-dns=XXX" and update the given DNS servers.

There's a package for that: openvpn-systemd-resolved

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to avahi in Ubuntu.
https://bugs.launchpad.net/bugs/1718227

Title:
  replacement of ifupdown with netplan needs integration for
  /etc/network/if{up,down}.d scripts

Status in aiccu package in Ubuntu:
  Invalid
Status in aoetools package in Ubuntu:
  New
Status in avahi package in Ubuntu:
  New
Status in bind9 package in Ubuntu:
  Invalid
Status in chrony package in Ubuntu:
  Fix Released
Status in clamav package in Ubuntu:
  Triaged
Status in controlaula package in Ubuntu:
  Invalid
Status in ethtool package in Ubuntu:
  Triaged
Status in guidedog package in Ubuntu:
  New
Status in htpdate package in Ubuntu:
  New
Status in ifenslave package in Ubuntu:
  Won't Fix
Status in ifmetric package in Ubuntu:
  Won't Fix
Status in ifupdown-multi package in Ubuntu:
  New
Status in ifupdown-scripts-zg2 package in Ubuntu:
  Invalid
Status in isatapd package in Ubuntu:
  New
Status in lprng package in Ubuntu:
  New
Status in miredo package in Ubuntu:
  New
Status in mythtv package in Ubuntu:
  New
Status in nplan package in Ubuntu:
  New
Status in nss-pam-ldapd package in Ubuntu:
  New
Status in ntp package in Ubuntu:
  Won't Fix
Status in openntpd package in Ubuntu:
  New
Status in openresolv package in Ubuntu:
  Won't Fix
Status in openssh package in Ubuntu:
  Fix Released
Status in openvpn package in Ubuntu:
  Confirmed
Status in openvswitch package in Ubuntu:
  Triaged
Status in postfix package in Ubuntu:
  New
Status in quicktun package in Ubuntu:
  New
Status in resolvconf package in Ubuntu:
  New
Status in sendmail package in Ubuntu:
  New
Status in shorewall-init package in Ubuntu:
  New
Status in sidedoor package in Ubuntu:
  New
Status in slrn package in Ubuntu:
  New
Status in tinc package in Ubuntu:
  New
Status in ubuntu-fan package in Ubuntu:
  Fix Released
Status in ucarp package in Ubuntu:
  New
Status in uml-utilities package in Ubuntu:
  New
Status in uruk package in Ubuntu:
  New
Status in vlan package in Ubuntu:
  Won't Fix
Status in vzctl package in Ubuntu:
  Triaged
Status in wide-dhcpv6 package in Ubuntu:
  New
Status in wpa package in Ubuntu:
  New

Bug description:
  when network is configured with ifupdown, scripts in
  /etc/network/ifup.d/ were called on network being brought up and
  /etc/network/ifdown.d were called on network being brought down.

  Any packages that shipped these hooks need to be verified to have the
  same functionality under a netplan configured system.

  # binpkgs=$(apt-file search /etc/network/if-up | sed 's,: .*,,' | sort -u)
  # for i in $binpkgs; do
src=$(apt-cache show $i | awk '$1 == "Source:" { print $2; exit(0); }');
[ -z "$src" ] && src="$i"; echo $src; done | sort -u

  aiccu
  aoetools
  avahi
  bind9
  chrony
  clamav
  controlaula
  epoptes
  ethtool
  guidedog
  htpdate
  ifenslave
  ifmetric
  ifupdown-extra
  ifupdown-multi
  ifupdown-scripts-zg2
  isatapd
  lprng
  miredo
  mythtv-backend
  nss-pam-ldapd
  ntp
  openntpd
  openresolv
  openssh
  openvpn
  postfix
  quicktun
  resolvconf
  sendmail
  shorewall-init
  sidedoor
  slrn
  tinc
  ubuntu-fan
  ucarp
  uml-utilities
  uruk
  vlan
  vzctl
  wide-dhcpv6
  wpa

  
  Related bugs:
   * bug 1718227: replacement of ifupdown with netplan needs integration for 
/etc/network/if{up,down}.d scripts 
   * bug 1713803: replacement of resolvconf with systemd needs integration 
   * bug 1717983: replacement of isc-dhcp-client with with systemd-networkd for 
dhclient needs integration

  
  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: netplan (not installed)
  ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5
  Uname: Linux 4.12.0-11-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Tue Sep 19 10:53:08 2017
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (789 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: plan
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1718227/+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 1718227] Re: replacement of ifupdown with netplan needs integration for /etc/network/if{up, down}.d scripts

2019-12-12 Thread Simon Déziel
> For openvpn + systemd-resolve:
>
> With "up / down" openvpn config file commands you can wrap "systemd-
> resolve --set-dns=XXX" and update the given DNS servers.

There's a package for that: openvpn-systemd-resolved

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to avahi in Ubuntu.
https://bugs.launchpad.net/bugs/1718227

Title:
  replacement of ifupdown with netplan needs integration for
  /etc/network/if{up,down}.d scripts

Status in aiccu package in Ubuntu:
  Invalid
Status in aoetools package in Ubuntu:
  New
Status in avahi package in Ubuntu:
  New
Status in bind9 package in Ubuntu:
  Invalid
Status in chrony package in Ubuntu:
  Fix Released
Status in clamav package in Ubuntu:
  Triaged
Status in controlaula package in Ubuntu:
  Invalid
Status in ethtool package in Ubuntu:
  Triaged
Status in guidedog package in Ubuntu:
  New
Status in htpdate package in Ubuntu:
  New
Status in ifenslave package in Ubuntu:
  Won't Fix
Status in ifmetric package in Ubuntu:
  Won't Fix
Status in ifupdown-multi package in Ubuntu:
  New
Status in ifupdown-scripts-zg2 package in Ubuntu:
  Invalid
Status in isatapd package in Ubuntu:
  New
Status in lprng package in Ubuntu:
  New
Status in miredo package in Ubuntu:
  New
Status in mythtv package in Ubuntu:
  New
Status in nplan package in Ubuntu:
  New
Status in nss-pam-ldapd package in Ubuntu:
  New
Status in ntp package in Ubuntu:
  Won't Fix
Status in openntpd package in Ubuntu:
  New
Status in openresolv package in Ubuntu:
  Won't Fix
Status in openssh package in Ubuntu:
  Fix Released
Status in openvpn package in Ubuntu:
  Confirmed
Status in openvswitch package in Ubuntu:
  Triaged
Status in postfix package in Ubuntu:
  New
Status in quicktun package in Ubuntu:
  New
Status in resolvconf package in Ubuntu:
  New
Status in sendmail package in Ubuntu:
  New
Status in shorewall-init package in Ubuntu:
  New
Status in sidedoor package in Ubuntu:
  New
Status in slrn package in Ubuntu:
  New
Status in tinc package in Ubuntu:
  New
Status in ubuntu-fan package in Ubuntu:
  Fix Released
Status in ucarp package in Ubuntu:
  New
Status in uml-utilities package in Ubuntu:
  New
Status in uruk package in Ubuntu:
  New
Status in vlan package in Ubuntu:
  Won't Fix
Status in vzctl package in Ubuntu:
  Triaged
Status in wide-dhcpv6 package in Ubuntu:
  New
Status in wpa package in Ubuntu:
  New

Bug description:
  when network is configured with ifupdown, scripts in
  /etc/network/ifup.d/ were called on network being brought up and
  /etc/network/ifdown.d were called on network being brought down.

  Any packages that shipped these hooks need to be verified to have the
  same functionality under a netplan configured system.

  # binpkgs=$(apt-file search /etc/network/if-up | sed 's,: .*,,' | sort -u)
  # for i in $binpkgs; do
src=$(apt-cache show $i | awk '$1 == "Source:" { print $2; exit(0); }');
[ -z "$src" ] && src="$i"; echo $src; done | sort -u

  aiccu
  aoetools
  avahi
  bind9
  chrony
  clamav
  controlaula
  epoptes
  ethtool
  guidedog
  htpdate
  ifenslave
  ifmetric
  ifupdown-extra
  ifupdown-multi
  ifupdown-scripts-zg2
  isatapd
  lprng
  miredo
  mythtv-backend
  nss-pam-ldapd
  ntp
  openntpd
  openresolv
  openssh
  openvpn
  postfix
  quicktun
  resolvconf
  sendmail
  shorewall-init
  sidedoor
  slrn
  tinc
  ubuntu-fan
  ucarp
  uml-utilities
  uruk
  vlan
  vzctl
  wide-dhcpv6
  wpa

  
  Related bugs:
   * bug 1718227: replacement of ifupdown with netplan needs integration for 
/etc/network/if{up,down}.d scripts 
   * bug 1713803: replacement of resolvconf with systemd needs integration 
   * bug 1717983: replacement of isc-dhcp-client with with systemd-networkd for 
dhclient needs integration

  
  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: netplan (not installed)
  ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5
  Uname: Linux 4.12.0-11-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Tue Sep 19 10:53:08 2017
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2015-07-23 (789 days ago)
  InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: plan
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1718227/+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 1800836] Re: systemd-networkd doesn't process IPv6 RA properly

2019-11-05 Thread Simon Déziel
fw01/02 have bond0.21 that is setup to have fe80::1 as the VIP used as
the network gateway:

root@fw01:~# ip -6 a show bond0.21
8: bond0.21@bond0:  mtu 1500 state UP qlen 1000
inet6 2620:a:b:21::2/64 scope global 
   valid_lft forever preferred_lft forever
inet6 fe80::210:18ff:fe77:b558/64 scope link 
   valid_lft forever preferred_lft forever

# fw02 is currently primary/master
root@fw02:~# ip -6 a show bond0.21
8: bond0.21@bond0:  mtu 1500 state UP qlen 1000
inet6 2620:a:b:21::3/64 scope global 
   valid_lft forever preferred_lft forever
inet6 fe80::1/64 scope link nodad 
   valid_lft forever preferred_lft forever
inet6 fe80::210:18ff:febe:6750/64 scope link 
   valid_lft forever preferred_lft forever

fw01/02 /etc/radvd.conf looks like this:

interface bond0.21
{
  AdvSendAdvert on;
  MaxRtrAdvInterval 30;

  prefix 2620:a:b:21::/64
  {
  };
};

and radvd only runs on the primary/master fw (02 ATM).

After a failover, Bionic clients using netplan/systemd-networkd will
have a bogus default nexthop like this:

$ ip -6 ro
2620:a:b:21::/64 dev eth0 proto ra metric 1024 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default proto ra metric 1024 
nexthop via fe80::1 dev eth0 weight 1 
nexthop via fe80::210:18ff:fe77:b558 dev eth0 weight 1 
nexthop via fe80::210:18ff:febe:6750 dev eth0 weight 1 

Preventing them from communicating properly. To fix this, one has to
manually do this:

sudo ip -6 ro del default proto ra && sudo netplan apply

Which then give the expected route entries like:

$ ip -6 ro
2620:a:b:21::/64 dev eth0 proto ra metric 1024 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::1 dev eth0 proto ra metric 1024 pref medium


On the other hand, machines using ifupdown (Xenial or Bionic) in the same 
network segment have no problem keeping only fe80::1 as the default nexthop.


** Changed in: systemd (Ubuntu)
   Status: Incomplete => Confirmed

-- 
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/1800836

Title:
  systemd-networkd doesn't process IPv6 RA properly

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  The gateways/firewalls in our DC are highly available and when there
  is a failover their IPv6 VIP (fe80::1) moves from the master to the
  backup one.

  We found that only our Bionic VMs behind those gateways had issues
  after a failover. Those Bionic VMs were all running systemd-networkd
  (from netplan) and before the failover they had:

  $ ip -6 route
  ...
  default via fe80::1 dev eth0 proto ra metric 1024 pref medium

  But after a failover:

  $ ip -6 route
  ...
  default proto ra metric 1024
  nexthop via fe80::1 dev eth0 weight 1
  nexthop via fe80::210:18ff:febe:6750 dev eth0 weight 1

  And after another failover:

  $ ip -6 route
  ...
  default proto ra metric 1024
  nexthop via fe80::1 dev eth0 weight 1
  nexthop via fe80::210:18ff:febe:6750 dev eth0 weight 1
  nexthop via fe80::210:18ff:fe77:b558 dev eth0 weight 1

  
  This is problematic as those then use fe80::210:18ff:fe77:b558%$IFACE as 
their default gateway even when this gateway is unavailable:

  $ ip -6 route get ::
  :: from :: via fe80::210:18ff:fe77:b558 dev eth0 proto ra src 
fe80::a800:ff:fe51:8c37 metric 1024 pref medium

  
  We concluded it was a systemd-networkd bug after checking that the following 
combinations were NOT affected:

  1) Xenial+4.4 kernel
  2) Xenial+4.15 kernel
  3) Bionic+ifupdown

  
  Additional information:

  $ apt-cache policy systemd
  systemd:
Installed: 237-3ubuntu10.3
Candidate: 237-3ubuntu10.3
Version table:
   *** 237-3ubuntu10.3 500
  500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   237-3ubuntu10 500
  500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages

  $ lsb_release -rd
  Description:  Ubuntu 18.04.1 LTS
  Release:  18.04

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu10.3
  ProcVersionSignature: Ubuntu 4.15.0-38.41-generic 4.15.18
  Uname: Linux 4.15.0-38-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.4
  Architecture: amd64
  Date: Wed Oct 31 08:47:28 2018
  Lspci: Error: [Errno 2] No such file or directory: 'lspci': 'lspci'
  Lsusb: Error: [Errno 2] No such file or directory: 'lsusb': 'lsusb'
  MachineType: QEMU Standard PC (i440FX + PIIX, 1996)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-38-generic 
root=UUID=43b7ee2e-2ab1-4505-8e0b-d9fe0563a034 ro console=ttyS0 net.ifnames=0 
vsyscall=none kaslr nmi_watchdog=0 possible_cpus=1
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)

[Touch-packages] [Bug 1827253] Re: [apparmor] missing 'mr' on binary for usage on containers

2019-10-30 Thread Simon Déziel
I feel really bad now :/

The initial commit that went in doesn't even fix the problem due to a
typo/confusion. The proposed manual workaround was OK but the merge
proposal was not.

 "/usr/sbin/rsyslog mr," != "/usr/sbin/rsyslogd mr,"

I'm failing the verification and have proposed a new MP. Sorry.

** Tags removed: verification-needed verification-needed-bionic 
verification-needed-disco
** Tags added: verification-failed verification-failed-bionic 
verification-failed-disco

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1827253

Title:
  [apparmor] missing 'mr' on binary for usage on containers

Status in rsyslog package in Ubuntu:
  Fix Released
Status in rsyslog source package in Bionic:
  Fix Committed
Status in rsyslog source package in Disco:
  Fix Committed

Bug description:
  [Impact]

   * rsyslog ships with a (Default disable) apparmor profile.
   * Security sensitive users are in general encouraged to enable such
     profiles but unfortunately due to slightly new behavior of the program
     the profile prevents its usage.
   * Allow the program to map/read its binary to get this working again

  [Test Case]

  1) Create a 'eoan' container called rs1 here:
    lxc launch ubuntu-daily:e rs1
  2) Enter the container
    lxc shell rs1
  3) Enable apparmor profile
    rm /etc/apparmor.d/disable/usr.sbin.rsyslogd
    apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
    systemctl restart rsyslog
  4) notice rsyslog failed to start
    systemctl status rsyslog

  [Regression Potential]

   * This is just opening up the apparmor profile a bit. Therefore the only
     regression it could cause IMHO is a security issue. But then what it
     actually allows is reading (not writing!) its own binary which should
     be very safe.
   * Thinking further it came to my mind that package updates (independent 
 to the change) might restart services and that means if there is any 
 issue e.g. in a local config that worked but now fails (not by this 
 change but in general) then the upgrade will not cause, but trigger 
 this. This is a general regression risk for any upload, but in this 
 case worth to mention as it is about log handling - which if broken - 
 makes large scale systems hard to debug.

  [Other Info]

   * n/a

  ---

  Issue description:

  Enabling the rsyslog (disabled by default) Apparmor profile causes
  rsyslog to fail to start when running *inside a container*.

  Steps to reproduce:

  1) Create a 'eoan' container called rs1 here:
    lxc launch ubuntu-daily:e rs1
  2) Enter the container
    lxc shell rs1
  3) Enable apparmor profile
    rm /etc/apparmor.d/disable/usr.sbin.rsyslogd
    apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
    systemctl restart rsyslog
  4) notice rsyslog failed to start
    systemctl status rsyslog

  Workaround:

    echo '  /usr/sbin/rsyslogd mr,' >> /etc/apparmor.d/local/usr.sbin.rsyslogd
    apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
    systemctl restart rsyslog

  Additional information:

  root@rs1:~# uname -a
  Linux rs1 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 
x86_64 x86_64 GNU/Linux
  root@rs1:~# lsb_release -rd
  Description:  Ubuntu Eoan EANIMAL (development branch)
  Release:  19.10
  root@rs1:~# dpkg -l| grep -wE 'apparmor|rsyslog'
  ii  apparmor 2.13.2-9ubuntu6  amd64user-space parser utility for 
AppArmor
  ii  rsyslog  8.32.0-1ubuntu7  amd64reliable system and kernel logging 
daemon

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: rsyslog 8.32.0-1ubuntu7
  ProcVersionSignature: Ubuntu 4.15.0-48.51-generic 4.15.18
  Uname: Linux 4.15.0-48-generic x86_64
  ApportVersion: 2.20.10-0ubuntu27
  Architecture: amd64
  Date: Wed May  1 17:36:29 2019
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: rsyslog
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1827253/+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 1827253] Re: [apparmor] missing 'mr' on binary for usage on containers

2019-10-25 Thread Simon Déziel
Thanks Łukasz and Christian. I find the block-proposed-* tags idea
interesting if that's not too much work on your side.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1827253

Title:
  [apparmor] missing 'mr' on binary for usage on containers

Status in rsyslog package in Ubuntu:
  Fix Released
Status in rsyslog source package in Bionic:
  Triaged
Status in rsyslog source package in Disco:
  Triaged

Bug description:
  [Impact]

   * rsyslog ships with a (Default disable) apparmor profile.
   * Security sensitive users are in general encouraged to enable such
     profiles but unfortunately due to slightly new behavior of the program
     the profile prevents its usage.
   * Allow the program to map/read its binary to get this working again

  [Test Case]

  1) Create a 'eoan' container called rs1 here:
    lxc launch ubuntu-daily:e rs1
  2) Enter the container
    lxc shell rs1
  3) Enable apparmor profile
    rm /etc/apparmor.d/disable/usr.sbin.rsyslogd
    apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
    systemctl restart rsyslog
  4) notice rsyslog failed to start
    systemctl status rsyslog

  [Regression Potential]

   * This is just opening up the apparmor profile a bit. Therefore the only
     regression it could cause IMHO is a security issue. But then what it
     actually allows is reading (not writing!) its own binary which should
     be very safe.
   * Thinking further it came to my mind that package updates (independent 
 to the change) might restart services and that means if there is any 
 issue e.g. in a local config that worked but now fails (not by this 
 change but in general) then the upgrade will not cause, but trigger 
 this. This is a general regression risk for any upload, but in this 
 case worth to mention as it is about log handling - which if broken - 
 makes large scale systems hard to debug.

  [Other Info]

   * n/a

  ---

  Issue description:

  Enabling the rsyslog (disabled by default) Apparmor profile causes
  rsyslog to fail to start when running *inside a container*.

  Steps to reproduce:

  1) Create a 'eoan' container called rs1 here:
    lxc launch ubuntu-daily:e rs1
  2) Enter the container
    lxc shell rs1
  3) Enable apparmor profile
    rm /etc/apparmor.d/disable/usr.sbin.rsyslogd
    apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
    systemctl restart rsyslog
  4) notice rsyslog failed to start
    systemctl status rsyslog

  Workaround:

    echo '  /usr/sbin/rsyslogd mr,' >> /etc/apparmor.d/local/usr.sbin.rsyslogd
    apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
    systemctl restart rsyslog

  Additional information:

  root@rs1:~# uname -a
  Linux rs1 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 
x86_64 x86_64 GNU/Linux
  root@rs1:~# lsb_release -rd
  Description:  Ubuntu Eoan EANIMAL (development branch)
  Release:  19.10
  root@rs1:~# dpkg -l| grep -wE 'apparmor|rsyslog'
  ii  apparmor 2.13.2-9ubuntu6  amd64user-space parser utility for 
AppArmor
  ii  rsyslog  8.32.0-1ubuntu7  amd64reliable system and kernel logging 
daemon

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: rsyslog 8.32.0-1ubuntu7
  ProcVersionSignature: Ubuntu 4.15.0-48.51-generic 4.15.18
  Uname: Linux 4.15.0-48-generic x86_64
  ApportVersion: 2.20.10-0ubuntu27
  Architecture: amd64
  Date: Wed May  1 17:36:29 2019
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: rsyslog
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1827253/+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 1827253] Re: [apparmor] missing 'mr' on binary for usage on containers

2019-10-04 Thread Simon Déziel
I'm hitting the same problem when using a Bionic host with a Bionic
container when using the 5.0 HWE kernel.

@paelzer, I'd appreciate if this could be SRU'ed to Bionic, please :)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1827253

Title:
  [apparmor] missing 'mr' on binary for usage on containers

Status in rsyslog package in Ubuntu:
  Fix Released

Bug description:
  Issue description:

  Enabling the rsyslog (disabled by default) Apparmor profile causes
  rsyslog to fail to start when running *inside a container*.

  Steps to reproduce:

  1) Create a 'eoan' container called rs1 here:
lxc launch ubuntu-daily:e rs1
  2) Enter the container
lxc shell rs1
  3) Enable apparmor profile
rm /etc/apparmor.d/disable/usr.sbin.rsyslogd
apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
systemctl restart rsyslog
  4) notice rsyslog failed to start
systemctl status rsyslog

  Workaround:

echo '  /usr/sbin/rsyslogd mr,' >> /etc/apparmor.d/local/usr.sbin.rsyslogd
apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
systemctl restart rsyslog

  
  Additional information:

  root@rs1:~# uname -a
  Linux rs1 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 
x86_64 x86_64 GNU/Linux
  root@rs1:~# lsb_release -rd
  Description:  Ubuntu Eoan EANIMAL (development branch)
  Release:  19.10
  root@rs1:~# dpkg -l| grep -wE 'apparmor|rsyslog'
  ii  apparmor 2.13.2-9ubuntu6  amd64user-space parser utility for 
AppArmor
  ii  rsyslog  8.32.0-1ubuntu7  amd64reliable system and kernel logging 
daemon

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: rsyslog 8.32.0-1ubuntu7
  ProcVersionSignature: Ubuntu 4.15.0-48.51-generic 4.15.18
  Uname: Linux 4.15.0-48-generic x86_64
  ApportVersion: 2.20.10-0ubuntu27
  Architecture: amd64
  Date: Wed May  1 17:36:29 2019
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: rsyslog
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1827253/+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 1841364] Re: AppArmor breaks the default Unbound installation in a live session

2019-08-30 Thread Simon Déziel
Yeah, this GetDynamicUsers denial is probably unrelated and should/will
be addressed in another bug. Thanks for double checking the alias trick!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1841364

Title:
  AppArmor breaks the default Unbound installation in a live session

Status in apparmor package in Ubuntu:
  New
Status in unbound package in Ubuntu:
  Triaged

Bug description:
  Immediately after installing Unbound, it starts up normally. However,
  if you try to restart it afterwards (without changing anything), it
  fails with the following error message:

  Aug 25 10:41:26 ubuntu unbound[6650]: /etc/unbound/unbound.conf:10: error: 
cannot open include file '/etc/unbound/unbound.conf.d/*.conf': No such file or 
directory
  Aug 25 10:41:26 ubuntu unbound[6650]: read /etc/unbound/unbound.conf failed: 
1 errors in configuration file
  Aug 25 10:41:26 ubuntu unbound[6650]: [1566729686] unbound[6650:0] fatal 
error: Could not read config file: /etc/unbound/unbound.conf. Maybe try unbound 
-dd, it stays on the commandline to see more errors, or unbound-checkconf

  There *are* files matching the above glob pattern, however:

  root@ubuntu:~# echo /etc/unbound/unbound.conf.d/*.conf
  /etc/unbound/unbound.conf.d/qname-minimisation.conf 
/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf

  unbound-checkconf, on the other hand, determines the configuration to
  be fine:

  root@ubuntu:~# unbound-checkconf 
  unbound-checkconf: no errors in /etc/unbound/unbound.conf

  In the kernel log I can see that AppArmor is the probable culprit:

  Aug 25 10:41:26 ubuntu kernel: audit: type=1400
  audit(1566729686.377:239): apparmor="DENIED" operation="open"
  profile="/usr/sbin/unbound" name="/upper/etc/unbound/unbound.conf.d/"
  pid=6650 comm="unbound" requested_mask="r" denied_mask="r" fsuid=0
  ouid=0

  Steps to reproduce:

  1. Download ubuntu-19.04-desktop-amd64.iso from 
https://ubuntu.com/download/desktop
  2. Boot the downloaded ISO file in a virtual machine
  3. Start gnome-terminal
  4. sudo -i
  5. apt-add-repository universe
  6. apt -y install unbound
  7. systemctl status unbound # verify that it is runnning
  8. systemctl restart unbound
  9. systemctl status unbound # verify that it failed to start
  10. journalctl -kn1 # display AppArmor error message

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1841364/+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


Re: [Touch-packages] [Bug 1827253] Re: [apparmor] missing 'mr' on binary for usage on containers

2019-07-03 Thread Simon Déziel
On 2019-07-03 10:47 a.m., Christian Ehrhardt  wrote:
> I feel bad that this hung around so log, but today I saw it and gave it a 
> review.
> This is building in Eoan now.

No worries for the delay, I know where to find you if something more
critical is taking too long to my taste ;) Thank you Christian!

Regards,
Simon

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1827253

Title:
  [apparmor] missing 'mr' on binary for usage on containers

Status in rsyslog package in Ubuntu:
  In Progress

Bug description:
  Issue description:

  Enabling the rsyslog (disabled by default) Apparmor profile causes
  rsyslog to fail to start when running *inside a container*.

  Steps to reproduce:

  1) Create a 'eoan' container called rs1 here:
lxc launch ubuntu-daily:e rs1
  2) Enter the container
lxc shell rs1
  3) Enable apparmor profile
rm /etc/apparmor.d/disable/usr.sbin.rsyslogd
apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
systemctl restart rsyslog
  4) notice rsyslog failed to start
systemctl status rsyslog

  Workaround:

echo '  /usr/sbin/rsyslogd mr,' >> /etc/apparmor.d/local/usr.sbin.rsyslogd
apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
systemctl restart rsyslog

  
  Additional information:

  root@rs1:~# uname -a
  Linux rs1 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 
x86_64 x86_64 GNU/Linux
  root@rs1:~# lsb_release -rd
  Description:  Ubuntu Eoan EANIMAL (development branch)
  Release:  19.10
  root@rs1:~# dpkg -l| grep -wE 'apparmor|rsyslog'
  ii  apparmor 2.13.2-9ubuntu6  amd64user-space parser utility for 
AppArmor
  ii  rsyslog  8.32.0-1ubuntu7  amd64reliable system and kernel logging 
daemon

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: rsyslog 8.32.0-1ubuntu7
  ProcVersionSignature: Ubuntu 4.15.0-48.51-generic 4.15.18
  Uname: Linux 4.15.0-48-generic x86_64
  ApportVersion: 2.20.10-0ubuntu27
  Architecture: amd64
  Date: Wed May  1 17:36:29 2019
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: rsyslog
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1827253/+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 1832370] Re: Unable to configure or disable TLS 1.3 via openssl.cnf

2019-06-14 Thread Simon Déziel
@xnox, thanks it was indeed an error on my part. The key was to have
openssl_conf in the default/unnamed section and then not introduce bogus
values: Ciphers is not recognized and causes the config section to be
ignored.

I believe this bug could be marked as Invalid for all the releases but
I'll let you do that as I only tested on Bionic and I don't want to
overrule the statuses you set. Thanks again!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1832370

Title:
  Unable to configure or disable TLS 1.3 via openssl.cnf

Status in openssl package in Ubuntu:
  Incomplete
Status in openssl source package in Bionic:
  Incomplete
Status in openssl source package in Cosmic:
  Incomplete
Status in openssl source package in Disco:
  Incomplete
Status in openssl source package in Eoan:
  Incomplete

Bug description:
  [Description]

  Since OpenSSL 1.1.1 was backported to Bionic, some (all?) applications
  gained access to TLS 1.3 by default. The applications that were not
  rebuilt against OpenSSL 1.1.1 can't tune the TLS 1.3 settings
  (protocol, ciphersuites selection, ciphersuites order) like it's
  possible with 1.2 and below. As such, one should turn to configuring
  /etc/ssl/openssl.cnf to alter TLS 1.3 settings.

  Here is how I'd expect to be able to turn off TLS 1.3:

  # diff -Naur /etc/ssl/openssl.cnf{.orig,}
  --- /etc/ssl/openssl.cnf.orig 2019-06-11 10:33:02.330143086 -0400
  +++ /etc/ssl/openssl.cnf  2019-06-11 11:15:23.805113804 -0400
  @@ -12,6 +12,16 @@
   HOME = .
   RANDFILE = $ENV::HOME/.rnd
   
  +ssl_conf = ssl_sect
  +
  +[ssl_sect]
  +
  +system_default = system_default_sect
  +
  +[system_default_sect]
  +
  +MaxProtocol = TLSv1.2
  +
   # Extra OBJECT IDENTIFIER info:
   #oid_file= $ENV::HOME/.oid
   oid_section  = new_oids

  This doesn't work as 'openssl s_client -connect
  rproxy.sdeziel.info:443' negotiates TLS 1.3 with
  TLS_AES_256_GCM_SHA384.

  
  Similarly, trying to change the 'Ciphers' or the 'Ciphersuites' list with:

  # diff -Naur /etc/ssl/openssl.cnf{.orig,}
  --- /etc/ssl/openssl.cnf.orig 2019-06-11 10:33:02.330143086 -0400
  +++ /etc/ssl/openssl.cnf  2019-06-11 11:37:23.362889367 -0400
  @@ -12,6 +12,17 @@
   HOME = .
   RANDFILE = $ENV::HOME/.rnd
   
  +ssl_conf = ssl_sect
  +
  +[ssl_sect]
  +
  +system_default = system_default_sect
  +
  +[system_default_sect]
  +
  +Ciphers = TLS_AES_128_GCM_SHA256
  +Ciphersuites = TLS_AES_128_GCM_SHA256
  +
   # Extra OBJECT IDENTIFIER info:
   #oid_file= $ENV::HOME/.oid
   oid_section  = new_oids

  Doesn't work as s_client keeps negotiating TLS 1.3 with
  TLS_AES_256_GCM_SHA384 (!= 128)

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: openssl 1.1.1-1ubuntu2.1~18.04.1
  ProcVersionSignature: Ubuntu 4.15.0-51.55-generic 4.15.18
  Uname: Linux 4.15.0-51-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Jun 11 11:22:47 2019
  InstallationDate: Installed on 2018-07-15 (331 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180714)
  ProcEnviron:
   LANG=en_CA.UTF-8
   TERM=xterm-256color
   SHELL=/bin/bash
   XDG_RUNTIME_DIR=
   PATH=(custom, no user)
  SourcePackage: openssl
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1832370/+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 1832370] Re: Unable to configure or disable TLS 1.3 via openssl.cnf

2019-06-11 Thread Simon Déziel
In my tests, I used NGINX with those TLS related params:

# grep -r ssl_ /etc/nginx/nginx.conf /etc/nginx/conf.d/ 
/etc/nginx/sites-enabled/
/etc/nginx/nginx.conf:  ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, 
ref: POODLE
/etc/nginx/nginx.conf:  ssl_prefer_server_ciphers on;
/etc/nginx/conf.d/ssl.conf:ssl_ciphers 
TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384;
/etc/nginx/conf.d/ssl.conf:ssl_session_cache   shared:SSL:1m;
/etc/nginx/conf.d/ssl.conf:ssl_session_timeout 1d;
/etc/nginx/conf.d/ssl.conf:ssl_session_tickets off;
/etc/nginx/conf.d/ssl.conf:ssl_certificate 
/etc/nginx/certs/sdeziel.info/fullchain.pem;
/etc/nginx/conf.d/ssl.conf:ssl_certificate_key 
/etc/nginx/certs/sdeziel.info/privkey.pem;
/etc/nginx/conf.d/ssl.conf:ssl_stapling on;


I used many variations of ssl_ciphers and ssl_protocols to no avail. My main 
goal is to have TLS 1.3 and 1.2 enabled with this ciphers list from above but 
that doesn't work as seen here: 
 
https://dev.ssllabs.com/ssltest/analyze.html?d=sdeziel.info=2001%3a470%3ab1c3%3a7942%3a0%3a0%3a0%3a80=on

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1832370

Title:
  Unable to configure or disable TLS 1.3 via openssl.cnf

Status in openssl package in Ubuntu:
  New

Bug description:
  [Description]

  Since OpenSSL 1.1.1 was backported to Bionic, some (all?) applications
  gained access to TLS 1.3 by default. The applications that were not
  rebuilt against OpenSSL 1.1.1 can't tune the TLS 1.3 settings
  (protocol, ciphersuites selection, ciphersuites order) like it's
  possible with 1.2 and below. As such, one should turn to configuring
  /etc/ssl/openssl.cnf to alter TLS 1.3 settings.

  Here is how I'd expect to be able to turn off TLS 1.3:

  # diff -Naur /etc/ssl/openssl.cnf{.orig,}
  --- /etc/ssl/openssl.cnf.orig 2019-06-11 10:33:02.330143086 -0400
  +++ /etc/ssl/openssl.cnf  2019-06-11 11:15:23.805113804 -0400
  @@ -12,6 +12,16 @@
   HOME = .
   RANDFILE = $ENV::HOME/.rnd
   
  +ssl_conf = ssl_sect
  +
  +[ssl_sect]
  +
  +system_default = system_default_sect
  +
  +[system_default_sect]
  +
  +MaxProtocol = TLSv1.2
  +
   # Extra OBJECT IDENTIFIER info:
   #oid_file= $ENV::HOME/.oid
   oid_section  = new_oids

  This doesn't work as 'openssl s_client -connect
  rproxy.sdeziel.info:443' negotiates TLS 1.3 with
  TLS_AES_256_GCM_SHA384.

  
  Similarly, trying to change the 'Ciphers' or the 'Ciphersuites' list with:

  # diff -Naur /etc/ssl/openssl.cnf{.orig,}
  --- /etc/ssl/openssl.cnf.orig 2019-06-11 10:33:02.330143086 -0400
  +++ /etc/ssl/openssl.cnf  2019-06-11 11:37:23.362889367 -0400
  @@ -12,6 +12,17 @@
   HOME = .
   RANDFILE = $ENV::HOME/.rnd
   
  +ssl_conf = ssl_sect
  +
  +[ssl_sect]
  +
  +system_default = system_default_sect
  +
  +[system_default_sect]
  +
  +Ciphers = TLS_AES_128_GCM_SHA256
  +Ciphersuites = TLS_AES_128_GCM_SHA256
  +
   # Extra OBJECT IDENTIFIER info:
   #oid_file= $ENV::HOME/.oid
   oid_section  = new_oids

  Doesn't work as s_client keeps negotiating TLS 1.3 with
  TLS_AES_256_GCM_SHA384 (!= 128)

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: openssl 1.1.1-1ubuntu2.1~18.04.1
  ProcVersionSignature: Ubuntu 4.15.0-51.55-generic 4.15.18
  Uname: Linux 4.15.0-51-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Jun 11 11:22:47 2019
  InstallationDate: Installed on 2018-07-15 (331 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180714)
  ProcEnviron:
   LANG=en_CA.UTF-8
   TERM=xterm-256color
   SHELL=/bin/bash
   XDG_RUNTIME_DIR=
   PATH=(custom, no user)
  SourcePackage: openssl
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1832370/+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 1832370] [NEW] Unable to configure or disable TLS 1.3 via openssl.cnf

2019-06-11 Thread Simon Déziel
Public bug reported:

[Description]

Since OpenSSL 1.1.1 was backported to Bionic, some (all?) applications
gained access to TLS 1.3 by default. The applications that were not
rebuilt against OpenSSL 1.1.1 can't tune the TLS 1.3 settings (protocol,
ciphersuites selection, ciphersuites order) like it's possible with 1.2
and below. As such, one should turn to configuring /etc/ssl/openssl.cnf
to alter TLS 1.3 settings.

Here is how I'd expect to be able to turn off TLS 1.3:

# diff -Naur /etc/ssl/openssl.cnf{.orig,}
--- /etc/ssl/openssl.cnf.orig   2019-06-11 10:33:02.330143086 -0400
+++ /etc/ssl/openssl.cnf2019-06-11 11:15:23.805113804 -0400
@@ -12,6 +12,16 @@
 HOME   = .
 RANDFILE   = $ENV::HOME/.rnd
 
+ssl_conf = ssl_sect
+
+[ssl_sect]
+
+system_default = system_default_sect
+
+[system_default_sect]
+
+MaxProtocol = TLSv1.2
+
 # Extra OBJECT IDENTIFIER info:
 #oid_file  = $ENV::HOME/.oid
 oid_section= new_oids

This doesn't work as 'openssl s_client -connect rproxy.sdeziel.info:443'
negotiates TLS 1.3 with TLS_AES_256_GCM_SHA384.


Similarly, trying to change the 'Ciphers' or the 'Ciphersuites' list with:

# diff -Naur /etc/ssl/openssl.cnf{.orig,}
--- /etc/ssl/openssl.cnf.orig   2019-06-11 10:33:02.330143086 -0400
+++ /etc/ssl/openssl.cnf2019-06-11 11:37:23.362889367 -0400
@@ -12,6 +12,17 @@
 HOME   = .
 RANDFILE   = $ENV::HOME/.rnd
 
+ssl_conf = ssl_sect
+
+[ssl_sect]
+
+system_default = system_default_sect
+
+[system_default_sect]
+
+Ciphers = TLS_AES_128_GCM_SHA256
+Ciphersuites = TLS_AES_128_GCM_SHA256
+
 # Extra OBJECT IDENTIFIER info:
 #oid_file  = $ENV::HOME/.oid
 oid_section= new_oids

Doesn't work as s_client keeps negotiating TLS 1.3 with
TLS_AES_256_GCM_SHA384 (!= 128)

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: openssl 1.1.1-1ubuntu2.1~18.04.1
ProcVersionSignature: Ubuntu 4.15.0-51.55-generic 4.15.18
Uname: Linux 4.15.0-51-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.9-0ubuntu7.6
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Tue Jun 11 11:22:47 2019
InstallationDate: Installed on 2018-07-15 (331 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180714)
ProcEnviron:
 LANG=en_CA.UTF-8
 TERM=xterm-256color
 SHELL=/bin/bash
 XDG_RUNTIME_DIR=
 PATH=(custom, no user)
SourcePackage: openssl
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: openssl (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug bionic rls-ee-incoming

** Attachment added: "openssl.cnf trying to disable TLS 1.3"
   
https://bugs.launchpad.net/bugs/1832370/+attachment/5270156/+files/openssl.cnf

** Attachment removed: "ProcCpuinfoMinimal.txt"
   
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1832370/+attachment/5270158/+files/ProcCpuinfoMinimal.txt

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1832370

Title:
  Unable to configure or disable TLS 1.3 via openssl.cnf

Status in openssl package in Ubuntu:
  New

Bug description:
  [Description]

  Since OpenSSL 1.1.1 was backported to Bionic, some (all?) applications
  gained access to TLS 1.3 by default. The applications that were not
  rebuilt against OpenSSL 1.1.1 can't tune the TLS 1.3 settings
  (protocol, ciphersuites selection, ciphersuites order) like it's
  possible with 1.2 and below. As such, one should turn to configuring
  /etc/ssl/openssl.cnf to alter TLS 1.3 settings.

  Here is how I'd expect to be able to turn off TLS 1.3:

  # diff -Naur /etc/ssl/openssl.cnf{.orig,}
  --- /etc/ssl/openssl.cnf.orig 2019-06-11 10:33:02.330143086 -0400
  +++ /etc/ssl/openssl.cnf  2019-06-11 11:15:23.805113804 -0400
  @@ -12,6 +12,16 @@
   HOME = .
   RANDFILE = $ENV::HOME/.rnd
   
  +ssl_conf = ssl_sect
  +
  +[ssl_sect]
  +
  +system_default = system_default_sect
  +
  +[system_default_sect]
  +
  +MaxProtocol = TLSv1.2
  +
   # Extra OBJECT IDENTIFIER info:
   #oid_file= $ENV::HOME/.oid
   oid_section  = new_oids

  This doesn't work as 'openssl s_client -connect
  rproxy.sdeziel.info:443' negotiates TLS 1.3 with
  TLS_AES_256_GCM_SHA384.

  
  Similarly, trying to change the 'Ciphers' or the 'Ciphersuites' list with:

  # diff -Naur /etc/ssl/openssl.cnf{.orig,}
  --- /etc/ssl/openssl.cnf.orig 2019-06-11 10:33:02.330143086 -0400
  +++ /etc/ssl/openssl.cnf  2019-06-11 11:37:23.362889367 -0400
  @@ -12,6 +12,17 @@
   HOME = .
   RANDFILE = $ENV::HOME/.rnd
   
  +ssl_conf = ssl_sect
  +
  +[ssl_sect]
  +
  +system_default = system_default_sect
  +
  +[system_default_sect]
  +
  +Ciphers = TLS_AES_128_GCM_SHA256
  +Ciphersuites = TLS_AES_128_GCM_SHA256
  +
   # Extra OBJECT IDENTIFIER info:
   

[Touch-packages] [Bug 1827253] [NEW] [apparmor] missing 'mr' on binary for usage on containers

2019-05-01 Thread Simon Déziel
Public bug reported:

Issue description:

Enabling the rsyslog (disabled by default) Apparmor profile causes
rsyslog to fail to start when running *inside a container*.

Steps to reproduce:

1) Create a 'eoan' container called rs1 here:
  lxc launch ubuntu-daily:e rs1
2) Enter the container
  lxc shell rs1
3) Enable apparmor profile
  rm /etc/apparmor.d/disable/usr.sbin.rsyslogd
  apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
  systemctl restart rsyslog
4) notice rsyslog failed to start
  systemctl status rsyslog

Workaround:

  echo '  /usr/sbin/rsyslogd mr,' >> /etc/apparmor.d/local/usr.sbin.rsyslogd
  apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
  systemctl restart rsyslog


Additional information:

root@rs1:~# uname -a
Linux rs1 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 
x86_64 x86_64 GNU/Linux
root@rs1:~# lsb_release -rd
Description:Ubuntu Eoan EANIMAL (development branch)
Release:19.10
root@rs1:~# dpkg -l| grep -wE 'apparmor|rsyslog'
ii  apparmor 2.13.2-9ubuntu6  amd64user-space parser utility for 
AppArmor
ii  rsyslog  8.32.0-1ubuntu7  amd64reliable system and kernel logging 
daemon

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: rsyslog 8.32.0-1ubuntu7
ProcVersionSignature: Ubuntu 4.15.0-48.51-generic 4.15.18
Uname: Linux 4.15.0-48-generic x86_64
ApportVersion: 2.20.10-0ubuntu27
Architecture: amd64
Date: Wed May  1 17:36:29 2019
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: rsyslog
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: rsyslog (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug eoan

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1827253

Title:
  [apparmor] missing 'mr' on binary for usage on containers

Status in rsyslog package in Ubuntu:
  New

Bug description:
  Issue description:

  Enabling the rsyslog (disabled by default) Apparmor profile causes
  rsyslog to fail to start when running *inside a container*.

  Steps to reproduce:

  1) Create a 'eoan' container called rs1 here:
lxc launch ubuntu-daily:e rs1
  2) Enter the container
lxc shell rs1
  3) Enable apparmor profile
rm /etc/apparmor.d/disable/usr.sbin.rsyslogd
apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
systemctl restart rsyslog
  4) notice rsyslog failed to start
systemctl status rsyslog

  Workaround:

echo '  /usr/sbin/rsyslogd mr,' >> /etc/apparmor.d/local/usr.sbin.rsyslogd
apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.rsyslogd
systemctl restart rsyslog

  
  Additional information:

  root@rs1:~# uname -a
  Linux rs1 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 
x86_64 x86_64 GNU/Linux
  root@rs1:~# lsb_release -rd
  Description:  Ubuntu Eoan EANIMAL (development branch)
  Release:  19.10
  root@rs1:~# dpkg -l| grep -wE 'apparmor|rsyslog'
  ii  apparmor 2.13.2-9ubuntu6  amd64user-space parser utility for 
AppArmor
  ii  rsyslog  8.32.0-1ubuntu7  amd64reliable system and kernel logging 
daemon

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: rsyslog 8.32.0-1ubuntu7
  ProcVersionSignature: Ubuntu 4.15.0-48.51-generic 4.15.18
  Uname: Linux 4.15.0-48-generic x86_64
  ApportVersion: 2.20.10-0ubuntu27
  Architecture: amd64
  Date: Wed May  1 17:36:29 2019
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: rsyslog
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1827253/+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 1800836] Re: systemd-networkd doesn't process IPv6 RA properly

2018-11-16 Thread Simon Déziel
systemd from Cosmic is not affected by this bug:

# apt-cache policy systemd
systemd:
  Installed: 239-7ubuntu10.3
  Candidate: 239-7ubuntu10.3
  Version table:
 *** 239-7ubuntu10.3 500
500 http://archive.ubuntu.com/ubuntu cosmic-updates/main amd64 Packages
500 http://archive.ubuntu.com/ubuntu cosmic-security/main amd64 Packages
100 /var/lib/dpkg/status
 239-7ubuntu10 500
500 http://archive.ubuntu.com/ubuntu cosmic/main amd64 Packages

** Summary changed:

- systemd-networkd doesn't IPv6 RA properly
+ systemd-networkd doesn't process IPv6 RA properly

-- 
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/1800836

Title:
  systemd-networkd doesn't process IPv6 RA properly

Status in systemd package in Ubuntu:
  New

Bug description:
  The gateways/firewalls in our DC are highly available and when there
  is a failover their IPv6 VIP (fe80::1) moves from the master to the
  backup one.

  We found that only our Bionic VMs behind those gateways had issues
  after a failover. Those Bionic VMs were all running systemd-networkd
  (from netplan) and before the failover they had:

  $ ip -6 route
  ...
  default via fe80::1 dev eth0 proto ra metric 1024 pref medium

  But after a failover:

  $ ip -6 route
  ...
  default proto ra metric 1024
  nexthop via fe80::1 dev eth0 weight 1
  nexthop via fe80::210:18ff:febe:6750 dev eth0 weight 1

  And after another failover:

  $ ip -6 route
  ...
  default proto ra metric 1024
  nexthop via fe80::1 dev eth0 weight 1
  nexthop via fe80::210:18ff:febe:6750 dev eth0 weight 1
  nexthop via fe80::210:18ff:fe77:b558 dev eth0 weight 1

  
  This is problematic as those then use fe80::210:18ff:fe77:b558%$IFACE as 
their default gateway even when this gateway is unavailable:

  $ ip -6 route get ::
  :: from :: via fe80::210:18ff:fe77:b558 dev eth0 proto ra src 
fe80::a800:ff:fe51:8c37 metric 1024 pref medium

  
  We concluded it was a systemd-networkd bug after checking that the following 
combinations were NOT affected:

  1) Xenial+4.4 kernel
  2) Xenial+4.15 kernel
  3) Bionic+ifupdown

  
  Additional information:

  $ apt-cache policy systemd
  systemd:
Installed: 237-3ubuntu10.3
Candidate: 237-3ubuntu10.3
Version table:
   *** 237-3ubuntu10.3 500
  500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   237-3ubuntu10 500
  500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages

  $ lsb_release -rd
  Description:  Ubuntu 18.04.1 LTS
  Release:  18.04

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu10.3
  ProcVersionSignature: Ubuntu 4.15.0-38.41-generic 4.15.18
  Uname: Linux 4.15.0-38-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.4
  Architecture: amd64
  Date: Wed Oct 31 08:47:28 2018
  Lspci: Error: [Errno 2] No such file or directory: 'lspci': 'lspci'
  Lsusb: Error: [Errno 2] No such file or directory: 'lsusb': 'lsusb'
  MachineType: QEMU Standard PC (i440FX + PIIX, 1996)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-38-generic 
root=UUID=43b7ee2e-2ab1-4505-8e0b-d9fe0563a034 ro console=ttyS0 net.ifnames=0 
vsyscall=none kaslr nmi_watchdog=0 possible_cpus=1
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 04/01/2014
  dmi.bios.vendor: SeaBIOS
  dmi.bios.version: Ubuntu-1.8.2-1ubuntu1
  dmi.chassis.type: 1
  dmi.chassis.vendor: QEMU
  dmi.chassis.version: pc-i440fx-xenial
  dmi.modalias: 
dmi:bvnSeaBIOS:bvrUbuntu-1.8.2-1ubuntu1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-xenial:cvnQEMU:ct1:cvrpc-i440fx-xenial:
  dmi.product.name: Standard PC (i440FX + PIIX, 1996)
  dmi.product.version: pc-i440fx-xenial
  dmi.sys.vendor: QEMU

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1800836/+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 1803601] [NEW] motd-news.service scheduled even when /etc/update-motd.d/50-motd-news is not executable

2018-11-15 Thread Simon Déziel
Public bug reported:

update-motd(5) says:

 Executable scripts in /etc/update-motd.d/* are executed by pam_motd(8) as the 
root user at each 
 login, and this information is concatenated in /run/motd.dynamic.  The order 
of  script  execu‐
 tion is determined by the run-parts(8) --lsbsysinit option (basically 
alphabetical order, with
 a few caveats).

So sysadmins are used to "chmod -x" motd fragments from /etc/update-
motd.d/ to prevent their execution. When doing so for /etc/update-
motd.d/50-motd-news, I noticed that motd-news.timer was still trying to
execute the motd-news.service unit which then logged a failure:

 systemd[3704]: motd-news.service: Failed to execute command: Permission denied
 systemd[3704]: motd-news.service: Failed at step EXEC spawning 
/etc/update-motd.d/50-motd-news:
  Permission denied
 systemd[1]: motd-news.service: Main process exited, code=exited, 
status=203/EXEC
 systemd[1]: motd-news.service: Failed with result 'exit-code'.
 systemd[1]: Failed to start Message of the Day.


This problem was observed on a Bionic system:

$ lsb_release -rd
Description:Ubuntu 18.04.1 LTS
Release:18.04
$ apt-cache policy base-files
base-files:
  Installed: 10.1ubuntu2.3
  Candidate: 10.1ubuntu2.3
  Version table:
 *** 10.1ubuntu2.3 500
500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
100 /var/lib/dpkg/status
 10.1ubuntu2.2 500
500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 
Packages
 10.1ubuntu2 500
500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages

But the problem also exist in Disco.

** Affects: base-files (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to base-files in Ubuntu.
https://bugs.launchpad.net/bugs/1803601

Title:
  motd-news.service scheduled even when /etc/update-motd.d/50-motd-news
  is not executable

Status in base-files package in Ubuntu:
  New

Bug description:
  update-motd(5) says:

   Executable scripts in /etc/update-motd.d/* are executed by pam_motd(8) as 
the root user at each 
   login, and this information is concatenated in /run/motd.dynamic.  The order 
of  script  execu‐
   tion is determined by the run-parts(8) --lsbsysinit option (basically 
alphabetical order, with
   a few caveats).

  So sysadmins are used to "chmod -x" motd fragments from /etc/update-
  motd.d/ to prevent their execution. When doing so for /etc/update-
  motd.d/50-motd-news, I noticed that motd-news.timer was still trying
  to execute the motd-news.service unit which then logged a failure:

   systemd[3704]: motd-news.service: Failed to execute command: Permission 
denied
   systemd[3704]: motd-news.service: Failed at step EXEC spawning 
/etc/update-motd.d/50-motd-news:
Permission denied
   systemd[1]: motd-news.service: Main process exited, code=exited, 
status=203/EXEC
   systemd[1]: motd-news.service: Failed with result 'exit-code'.
   systemd[1]: Failed to start Message of the Day.

  
  This problem was observed on a Bionic system:

  $ lsb_release -rd
  Description:  Ubuntu 18.04.1 LTS
  Release:  18.04
  $ apt-cache policy base-files
  base-files:
Installed: 10.1ubuntu2.3
Candidate: 10.1ubuntu2.3
Version table:
   *** 10.1ubuntu2.3 500
  500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   10.1ubuntu2.2 500
  500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 
Packages
   10.1ubuntu2 500
  500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages

  But the problem also exist in Disco.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1803601/+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 1803601] Re: motd-news.service scheduled even when /etc/update-motd.d/50-motd-news is not executable

2018-11-15 Thread Simon Déziel
A possible fix would be to make the unit execution conditional to the
update-motd fragment being executable:

  [Unit]
  ConditionFileIsExecutable=/etc/update-motd.d/50-motd-news

I'm not sure if this should be added to motd-news.service, motd-
news.timer or both.

** Description changed:

  update-motd(5) says:
  
-  Executable scripts in /etc/update-motd.d/* are executed by pam_motd(8) as 
the root user at each 
-  login, and this information is concatenated in /run/motd.dynamic.  The order 
of  script  execu‐
-  tion is determined by the run-parts(8) --lsbsysinit option (basically 
alphabetical order, with
-  a few caveats).
+  Executable scripts in /etc/update-motd.d/* are executed by pam_motd(8) as 
the root user at each
+  login, and this information is concatenated in /run/motd.dynamic.  The order 
of  script  execu‐
+  tion is determined by the run-parts(8) --lsbsysinit option (basically 
alphabetical order, with
+  a few caveats).
  
  So sysadmins are used to "chmod -x" motd fragments from /etc/update-
  motd.d/ to prevent their execution. When doing so for /etc/update-
  motd.d/50-motd-news, I noticed that motd-news.timer was still trying to
  execute the motd-news.service unit which then logged a failure:
  
-  systemd[3704]: motd-news.service: Failed to execute command: Permission 
denied
-  systemd[3704]: motd-news.service: Failed at step EXEC spawning 
/etc/update-motd.d/50-motd-news:
-   Permission denied
-  systemd[1]: motd-news.service: Main process exited, code=exited, 
status=203/EXEC
-  systemd[1]: motd-news.service: Failed with result 'exit-code'.
-  systemd[1]: Failed to start Message of the Day.
+  systemd[3704]: motd-news.service: Failed to execute command: Permission 
denied
+  systemd[3704]: motd-news.service: Failed at step EXEC spawning 
/etc/update-motd.d/50-motd-news:
+   Permission denied
+  systemd[1]: motd-news.service: Main process exited, code=exited, 
status=203/EXEC
+  systemd[1]: motd-news.service: Failed with result 'exit-code'.
+  systemd[1]: Failed to start Message of the Day.
+ 
+ 
+ The motd-news.service unit looks like this:
+ 
+ $ systemctl cat motd-news.service
+ # /lib/systemd/system/motd-news.service
+ [Unit]
+ Description=Message of the Day
+ After=network-online.target
+ Documentation=man:update-motd(8)
+ 
+ [Service]
+ Type=oneshot
+ ExecStart=/etc/update-motd.d/50-motd-news --force
  
  
  This problem was observed on a Bionic system:
  
  $ lsb_release -rd
  Description:  Ubuntu 18.04.1 LTS
  Release:  18.04
  $ apt-cache policy base-files
  base-files:
-   Installed: 10.1ubuntu2.3
-   Candidate: 10.1ubuntu2.3
-   Version table:
-  *** 10.1ubuntu2.3 500
- 500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
- 100 /var/lib/dpkg/status
-  10.1ubuntu2.2 500
- 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 
Packages
-  10.1ubuntu2 500
- 500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages
+   Installed: 10.1ubuntu2.3
+   Candidate: 10.1ubuntu2.3
+   Version table:
+  *** 10.1ubuntu2.3 500
+ 500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
+ 100 /var/lib/dpkg/status
+  10.1ubuntu2.2 500
+ 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 
Packages
+  10.1ubuntu2 500
+ 500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages
  
  But the problem also exist in Disco.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to base-files in Ubuntu.
https://bugs.launchpad.net/bugs/1803601

Title:
  motd-news.service scheduled even when /etc/update-motd.d/50-motd-news
  is not executable

Status in base-files package in Ubuntu:
  New

Bug description:
  update-motd(5) says:

   Executable scripts in /etc/update-motd.d/* are executed by pam_motd(8) as 
the root user at each
   login, and this information is concatenated in /run/motd.dynamic.  The order 
of  script  execu‐
   tion is determined by the run-parts(8) --lsbsysinit option (basically 
alphabetical order, with
   a few caveats).

  So sysadmins are used to "chmod -x" motd fragments from /etc/update-
  motd.d/ to prevent their execution. When doing so for /etc/update-
  motd.d/50-motd-news, I noticed that motd-news.timer was still trying
  to execute the motd-news.service unit which then logged a failure:

   systemd[3704]: motd-news.service: Failed to execute command: Permission 
denied
   systemd[3704]: motd-news.service: Failed at step EXEC spawning 
/etc/update-motd.d/50-motd-news:
    Permission denied
   systemd[1]: motd-news.service: Main process exited, code=exited, 
status=203/EXEC
   systemd[1]: motd-news.service: Failed with result 'exit-code'.
   systemd[1]: Failed to start Message of the Day.

  
  The motd-news.service unit looks like this:

  $ systemctl cat motd-news.service
  # /lib/systemd/system/motd-news.service
  [Unit]
  Description=Message of the 

[Touch-packages] [Bug 216847] Re: sshd will not start at boot if ListenAddress is set, because network interface is not yet up

2018-11-14 Thread Simon Déziel
Sorry, it should have read "After=network-online.target".

https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/#cutthecraphowdoimakesurethatmyservicestartsafterthenetworkisreallyonline

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/216847

Title:
  sshd will not start at boot if ListenAddress is set, because network
  interface is not yet up

Status in portable OpenSSH:
  Unknown
Status in openssh package in Ubuntu:
  Confirmed

Bug description:
  Binary package hint: openssh-server

  The sshd will not start at boot if the ListenAddress option in
  /etc/ssh/sshd_config is set to an IPv4 address other then 0.0.0.0 .

  I am using Ubuntu 7.10 and the version 1:4.6p1-5ubuntu0.2 of the 
openssh-server package.
  I would expect that sshd is started after boot but it will not and I found 
this in /var/log/auth.log:

  sshd[4527]: error: Bind to port 22 on 10.1.1.22 failed: Cannot assign 
requested address.
  sshd[4527]: fatal: Cannot bind any address.

  Once the System is started you can start/stop the sshd with the
  /etc/init.d/ssh script without any problems.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openssh/+bug/216847/+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 216847] Re: sshd will not start at boot if ListenAddress is set, because network interface is not yet up

2018-11-14 Thread Simon Déziel
@Rodman, as a workaround, maybe you could try to add an "After=systemd-
networkd-wait-online.service" clause in a drop-in snippet?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/216847

Title:
  sshd will not start at boot if ListenAddress is set, because network
  interface is not yet up

Status in portable OpenSSH:
  Unknown
Status in openssh package in Ubuntu:
  Confirmed

Bug description:
  Binary package hint: openssh-server

  The sshd will not start at boot if the ListenAddress option in
  /etc/ssh/sshd_config is set to an IPv4 address other then 0.0.0.0 .

  I am using Ubuntu 7.10 and the version 1:4.6p1-5ubuntu0.2 of the 
openssh-server package.
  I would expect that sshd is started after boot but it will not and I found 
this in /var/log/auth.log:

  sshd[4527]: error: Bind to port 22 on 10.1.1.22 failed: Cannot assign 
requested address.
  sshd[4527]: fatal: Cannot bind any address.

  Once the System is started you can start/stop the sshd with the
  /etc/init.d/ssh script without any problems.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openssh/+bug/216847/+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 1800836] [NEW] systemd-networkd doesn't IPv6 RA properly

2018-10-31 Thread Simon Déziel
Public bug reported:

The gateways/firewalls in our DC are highly available and when there is
a failover their IPv6 VIP (fe80::1) moves from the master to the backup
one.

We found that only our Bionic VMs behind those gateways had issues after
a failover. Those Bionic VMs were all running systemd-networkd (from
netplan) and before the failover they had:

$ ip -6 route
...
default via fe80::1 dev eth0 proto ra metric 1024 pref medium

But after a failover:

$ ip -6 route
...
default proto ra metric 1024
nexthop via fe80::1 dev eth0 weight 1
nexthop via fe80::210:18ff:febe:6750 dev eth0 weight 1

And after another failover:

$ ip -6 route
...
default proto ra metric 1024
nexthop via fe80::1 dev eth0 weight 1
nexthop via fe80::210:18ff:febe:6750 dev eth0 weight 1
nexthop via fe80::210:18ff:fe77:b558 dev eth0 weight 1


This is problematic as those then use fe80::210:18ff:fe77:b558%$IFACE as their 
default gateway even when this gateway is unavailable:

$ ip -6 route get ::
:: from :: via fe80::210:18ff:fe77:b558 dev eth0 proto ra src 
fe80::a800:ff:fe51:8c37 metric 1024 pref medium


We concluded it was a systemd-networkd bug after checking that the following 
combinations were NOT affected:

1) Xenial+4.4 kernel
2) Xenial+4.15 kernel
3) Bionic+ifupdown


Additional information:

$ apt-cache policy systemd
systemd:
  Installed: 237-3ubuntu10.3
  Candidate: 237-3ubuntu10.3
  Version table:
 *** 237-3ubuntu10.3 500
500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
100 /var/lib/dpkg/status
 237-3ubuntu10 500
500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages

$ lsb_release -rd
Description:Ubuntu 18.04.1 LTS
Release:18.04

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: systemd 237-3ubuntu10.3
ProcVersionSignature: Ubuntu 4.15.0-38.41-generic 4.15.18
Uname: Linux 4.15.0-38-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.4
Architecture: amd64
Date: Wed Oct 31 08:47:28 2018
Lspci: Error: [Errno 2] No such file or directory: 'lspci': 'lspci'
Lsusb: Error: [Errno 2] No such file or directory: 'lsusb': 'lsusb'
MachineType: QEMU Standard PC (i440FX + PIIX, 1996)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-38-generic 
root=UUID=43b7ee2e-2ab1-4505-8e0b-d9fe0563a034 ro console=ttyS0 net.ifnames=0 
vsyscall=none kaslr nmi_watchdog=0 possible_cpus=1
SourcePackage: systemd
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/01/2014
dmi.bios.vendor: SeaBIOS
dmi.bios.version: Ubuntu-1.8.2-1ubuntu1
dmi.chassis.type: 1
dmi.chassis.vendor: QEMU
dmi.chassis.version: pc-i440fx-xenial
dmi.modalias: 
dmi:bvnSeaBIOS:bvrUbuntu-1.8.2-1ubuntu1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-xenial:cvnQEMU:ct1:cvrpc-i440fx-xenial:
dmi.product.name: Standard PC (i440FX + PIIX, 1996)
dmi.product.version: pc-i440fx-xenial
dmi.sys.vendor: QEMU

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug bionic

-- 
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/1800836

Title:
  systemd-networkd doesn't IPv6 RA properly

Status in systemd package in Ubuntu:
  New

Bug description:
  The gateways/firewalls in our DC are highly available and when there
  is a failover their IPv6 VIP (fe80::1) moves from the master to the
  backup one.

  We found that only our Bionic VMs behind those gateways had issues
  after a failover. Those Bionic VMs were all running systemd-networkd
  (from netplan) and before the failover they had:

  $ ip -6 route
  ...
  default via fe80::1 dev eth0 proto ra metric 1024 pref medium

  But after a failover:

  $ ip -6 route
  ...
  default proto ra metric 1024
  nexthop via fe80::1 dev eth0 weight 1
  nexthop via fe80::210:18ff:febe:6750 dev eth0 weight 1

  And after another failover:

  $ ip -6 route
  ...
  default proto ra metric 1024
  nexthop via fe80::1 dev eth0 weight 1
  nexthop via fe80::210:18ff:febe:6750 dev eth0 weight 1
  nexthop via fe80::210:18ff:fe77:b558 dev eth0 weight 1

  
  This is problematic as those then use fe80::210:18ff:fe77:b558%$IFACE as 
their default gateway even when this gateway is unavailable:

  $ ip -6 route get ::
  :: from :: via fe80::210:18ff:fe77:b558 dev eth0 proto ra src 
fe80::a800:ff:fe51:8c37 metric 1024 pref medium

  
  We concluded it was a systemd-networkd bug after checking that the following 
combinations were NOT affected:

  1) Xenial+4.4 kernel
  2) Xenial+4.15 kernel
  3) Bionic+ifupdown

  
  Additional information:

  $ apt-cache policy systemd
  systemd:
Installed: 237-3ubuntu10.3
Candidate: 237-3ubuntu10.3
Version table:
   *** 237-3ubuntu10.3 500
  500 

[Touch-packages] [Bug 1427807] Re: usermod's man refers to --*-sub-uids but accepts only --*-subuids

2018-08-17 Thread Simon Déziel
The bug is fixed in Bionic.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to shadow in Ubuntu.
https://bugs.launchpad.net/bugs/1427807

Title:
  usermod's man refers to --*-sub-uids but accepts only --*-subuids

Status in shadow package in Ubuntu:
  Won't Fix

Bug description:
  The man page refers to sub-uids and sub-gids but those don't take any
  "-" between sub and [ug]ids. The help message conforms to what the
  command accepts though.

  $ man usermod | grep -F -- -sub
 -v, --add-sub-uids FIRST-LAST
 -V, --del-sub-uids FIRST-LAST
 This option may be specified multiple times to remove multiple 
ranges to a users account. When both --del-sub-uids and --add-sub-uids are 
specified remove of all subordinate uid ranges happens before any
 -w, --add-sub-gids FIRST-LAST
 -W, --del-sub-gids FIRST-LAST
 This option may be specified multiple times to remove multiple 
ranges to a users account. When both --del-sub-gids and --add-sub-gids are 
specified remove of all subordinate gid ranges happens before any

  $ usermod --help | grep -F -- -sub
-v, --add-subuids FIRST-LAST  add range of subordinate uids
-V, --del-subuids FIRST-LAST  remvoe range of subordinate uids
-w, --add-subgids FIRST-LAST  add range of subordinate gids
-W, --del-subgids FIRST-LAST  remvoe range of subordinate gids

  
  More info on the environment:

  $ lsb_release -rd
  Description:  Ubuntu 14.04.2 LTS
  Release:  14.04

  $ apt-cache policy passwd
  passwd:
Installed: 1:4.1.5.1-1ubuntu9
Candidate: 1:4.1.5.1-1ubuntu9
Version table:
   *** 1:4.1.5.1-1ubuntu9 0
  500 http://archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
  100 /var/lib/dpkg/status

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: passwd 1:4.1.5.1-1ubuntu9
  ProcVersionSignature: Ubuntu 3.13.0-46.77-generic 3.13.11-ckt15
  Uname: Linux 3.13.0-46-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3.7
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Tue Mar  3 13:37:50 2015
  InstallationDate: Installed on 2014-01-26 (400 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140124)
  SourcePackage: shadow
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1427807/+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 1787396] Re: ss crashes when using --no-header

2018-08-16 Thread Simon Déziel
This is fixed in Debian since 4.16.0-4 at least.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iproute2 in Ubuntu.
https://bugs.launchpad.net/bugs/1787396

Title:
  ss crashes when using --no-header

Status in iproute2 package in Ubuntu:
  Confirmed

Bug description:
  Steps to reproduce:

  1) Listen on port 8989:
  $ nc -l 8989 &

  2) Check that ss can list this listener:
  $ ss --no-header -nto state listening 'sport = 8989'
  010.0.0.0:8989  0.0.0.0:*

  3) Ask ss to list listeners on a port where nothing listens
  $ kill %1 # stops nc
  $ ss --no-header -nto state listening 'sport = 8989'
  Segmentation fault (core dumped)

  In the above, removing "--no-header" avoids the segfault.

  
  Additional information:

  $ lsb_release -rd
  Description:  Ubuntu 18.04.1 LTS
  Release:  18.04
  $ apt-cache policy iproute2
  iproute2:
Installed: 4.15.0-2ubuntu1
Candidate: 4.15.0-2ubuntu1
Version table:
   *** 4.15.0-2ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages
  100 /var/lib/dpkg/status

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: iproute2 4.15.0-2ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-32.35-generic 4.15.18
  Uname: Linux 4.15.0-32-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Aug 16 08:17:52 2018
  InstallationDate: Installed on 2018-07-15 (32 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180714)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_CA.UTF-8
   SHELL=/bin/bash
  SourcePackage: iproute2
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1787396/+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 1787396] Re: ss crashes when using --no-header

2018-08-16 Thread Simon Déziel
This also happens on Cosmic that has the same version of ss/iproute2:

# apt-cache policy iproute2
iproute2:
  Installed: 4.15.0-2ubuntu1
  Candidate: 4.15.0-2ubuntu1
  Version table:
 *** 4.15.0-2ubuntu1 500
500 http://archive.ubuntu.com/ubuntu cosmic/main amd64 Packages
100 /var/lib/dpkg/status

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iproute2 in Ubuntu.
https://bugs.launchpad.net/bugs/1787396

Title:
  ss crashes when using --no-header

Status in iproute2 package in Ubuntu:
  Confirmed

Bug description:
  Steps to reproduce:

  1) Listen on port 8989:
  $ nc -l 8989 &

  2) Check that ss can list this listener:
  $ ss --no-header -nto state listening 'sport = 8989'
  010.0.0.0:8989  0.0.0.0:*

  3) Ask ss to list listeners on a port where nothing listens
  $ kill %1 # stops nc
  $ ss --no-header -nto state listening 'sport = 8989'
  Segmentation fault (core dumped)

  In the above, removing "--no-header" avoids the segfault.

  
  Additional information:

  $ lsb_release -rd
  Description:  Ubuntu 18.04.1 LTS
  Release:  18.04
  $ apt-cache policy iproute2
  iproute2:
Installed: 4.15.0-2ubuntu1
Candidate: 4.15.0-2ubuntu1
Version table:
   *** 4.15.0-2ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages
  100 /var/lib/dpkg/status

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: iproute2 4.15.0-2ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-32.35-generic 4.15.18
  Uname: Linux 4.15.0-32-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Aug 16 08:17:52 2018
  InstallationDate: Installed on 2018-07-15 (32 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180714)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_CA.UTF-8
   SHELL=/bin/bash
  SourcePackage: iproute2
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1787396/+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 1787396] [NEW] ss crashes when using --no-header

2018-08-16 Thread Simon Déziel
Public bug reported:

Steps to reproduce:

1) Listen on port 8989:
$ nc -l 8989 &

2) Check that ss can list this listener:
$ ss --no-header -nto state listening 'sport = 8989'
010.0.0.0:8989  0.0.0.0:*

3) Ask ss to list listeners on a port where nothing listens
$ kill %1 # stops nc
$ ss --no-header -nto state listening 'sport = 8989'
Segmentation fault (core dumped)

In the above, removing "--no-header" avoids the segfault.


Additional information:

$ lsb_release -rd
Description:Ubuntu 18.04.1 LTS
Release:18.04
$ apt-cache policy iproute2
iproute2:
  Installed: 4.15.0-2ubuntu1
  Candidate: 4.15.0-2ubuntu1
  Version table:
 *** 4.15.0-2ubuntu1 500
500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages
100 /var/lib/dpkg/status

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: iproute2 4.15.0-2ubuntu1
ProcVersionSignature: Ubuntu 4.15.0-32.35-generic 4.15.18
Uname: Linux 4.15.0-32-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Thu Aug 16 08:17:52 2018
InstallationDate: Installed on 2018-07-15 (32 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180714)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=en_CA.UTF-8
 SHELL=/bin/bash
SourcePackage: iproute2
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: iproute2 (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug bionic

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iproute2 in Ubuntu.
https://bugs.launchpad.net/bugs/1787396

Title:
  ss crashes when using --no-header

Status in iproute2 package in Ubuntu:
  New

Bug description:
  Steps to reproduce:

  1) Listen on port 8989:
  $ nc -l 8989 &

  2) Check that ss can list this listener:
  $ ss --no-header -nto state listening 'sport = 8989'
  010.0.0.0:8989  0.0.0.0:*

  3) Ask ss to list listeners on a port where nothing listens
  $ kill %1 # stops nc
  $ ss --no-header -nto state listening 'sport = 8989'
  Segmentation fault (core dumped)

  In the above, removing "--no-header" avoids the segfault.

  
  Additional information:

  $ lsb_release -rd
  Description:  Ubuntu 18.04.1 LTS
  Release:  18.04
  $ apt-cache policy iproute2
  iproute2:
Installed: 4.15.0-2ubuntu1
Candidate: 4.15.0-2ubuntu1
Version table:
   *** 4.15.0-2ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages
  100 /var/lib/dpkg/status

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: iproute2 4.15.0-2ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-32.35-generic 4.15.18
  Uname: Linux 4.15.0-32-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Aug 16 08:17:52 2018
  InstallationDate: Installed on 2018-07-15 (32 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180714)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_CA.UTF-8
   SHELL=/bin/bash
  SourcePackage: iproute2
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1787396/+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 1786471] Re: remove 1024D keys from ubuntu-keyring on older LTS

2018-08-10 Thread Simon Déziel
** Description changed:

  Zesty and later (LP: #1363482) are no longer shipping with 1024D keys
  but older LTS releases (Trusty/Xenial) still trust those weak keys:
  
  $ lsb_release -sc
  xenial
  
  $ apt-key list
  /etc/apt/trusted.gpg
  
  pub   1024D/437D05B5 2004-09-12
  uid  Ubuntu Archive Automatic Signing Key 

  sub   2048g/79164387 2004-09-12
  
  pub   4096R/C0B21F32 2012-05-11
  uid  Ubuntu Archive Automatic Signing Key (2012) 

  
  pub   4096R/EFE21092 2012-05-11
  uid  Ubuntu CD Image Automatic Signing Key (2012) 

  
  pub   1024D/FBB75451 2004-12-30
  uid  Ubuntu CD Image Automatic Signing Key 

  
- 
  On Xenial, I found no problem after deleting the 2 1024D keys:
  
- $ sudo apt-key del 2A38B3EB
+ $ sudo apt-key del FBB75451
  $ sudo apt-key del 437D05B5
  $ sudo apt-get -qq update
  $ echo $? # returned 0
  
+ On Trusty, it seems that removing the key 437D05B5 leads to warnings due
+ to the double-signing:
  
- On Trusty, it seems that removing the key 437D05B5 leads to warnings due to 
the double-signing:
- 
- $ sudo apt-key del 2A38B3EB
+ $ sudo apt-key del FBB75451
  $ sudo apt-key del 437D05B5
  $ sudo apt-get -qq update
  W: There is no public key available for the following key IDs:
  40976EAF437D05B5
  W: There is no public key available for the following key IDs:
  40976EAF437D05B5
  W: There is no public key available for the following key IDs:
  40976EAF437D05B5
  $ echo $? # returned 0
  
  It seems that "apt-get update" is still happy as it can validate using
  the stronger key.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu-keyring in Ubuntu.
https://bugs.launchpad.net/bugs/1786471

Title:
  remove 1024D keys from ubuntu-keyring on older LTS

Status in ubuntu-keyring package in Ubuntu:
  New

Bug description:
  Zesty and later (LP: #1363482) are no longer shipping with 1024D keys
  but older LTS releases (Trusty/Xenial) still trust those weak keys:

  $ lsb_release -sc
  xenial

  $ apt-key list
  /etc/apt/trusted.gpg
  
  pub   1024D/437D05B5 2004-09-12
  uid  Ubuntu Archive Automatic Signing Key 

  sub   2048g/79164387 2004-09-12

  pub   4096R/C0B21F32 2012-05-11
  uid  Ubuntu Archive Automatic Signing Key (2012) 


  pub   4096R/EFE21092 2012-05-11
  uid  Ubuntu CD Image Automatic Signing Key (2012) 


  pub   1024D/FBB75451 2004-12-30
  uid  Ubuntu CD Image Automatic Signing Key 


  On Xenial, I found no problem after deleting the 2 1024D keys:

  $ sudo apt-key del FBB75451
  $ sudo apt-key del 437D05B5
  $ sudo apt-get -qq update
  $ echo $? # returned 0

  On Trusty, it seems that removing the key 437D05B5 leads to warnings
  due to the double-signing:

  $ sudo apt-key del FBB75451
  $ sudo apt-key del 437D05B5
  $ sudo apt-get -qq update
  W: There is no public key available for the following key IDs:
  40976EAF437D05B5
  W: There is no public key available for the following key IDs:
  40976EAF437D05B5
  W: There is no public key available for the following key IDs:
  40976EAF437D05B5
  $ echo $? # returned 0

  It seems that "apt-get update" is still happy as it can validate using
  the stronger key.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-keyring/+bug/1786471/+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 1786471] [NEW] remove 1024D keys from ubuntu-keyring on older LTS

2018-08-10 Thread Simon Déziel
*** This bug is a security vulnerability ***

Public security bug reported:

Zesty and later (LP: #1363482) are no longer shipping with 1024D keys
but older LTS releases (Trusty/Xenial) still trust those weak keys:

$ lsb_release -sc
xenial

$ apt-key list
/etc/apt/trusted.gpg

pub   1024D/437D05B5 2004-09-12
uid  Ubuntu Archive Automatic Signing Key 
sub   2048g/79164387 2004-09-12

pub   4096R/C0B21F32 2012-05-11
uid  Ubuntu Archive Automatic Signing Key (2012) 


pub   4096R/EFE21092 2012-05-11
uid  Ubuntu CD Image Automatic Signing Key (2012) 


pub   1024D/FBB75451 2004-12-30
uid  Ubuntu CD Image Automatic Signing Key 


On Xenial, I found no problem after deleting the 2 1024D keys:

$ sudo apt-key del 2A38B3EB
$ sudo apt-key del 437D05B5
$ sudo apt-get -qq update
$ echo $? # returned 0


On Trusty, it seems that removing the key 437D05B5 leads to warnings due to the 
double-signing:

$ sudo apt-key del 2A38B3EB
$ sudo apt-key del 437D05B5
$ sudo apt-get -qq update
W: There is no public key available for the following key IDs:
40976EAF437D05B5
W: There is no public key available for the following key IDs:
40976EAF437D05B5
W: There is no public key available for the following key IDs:
40976EAF437D05B5
$ echo $? # returned 0

It seems that "apt-get update" is still happy as it can validate using
the stronger key.

** Affects: ubuntu-keyring (Ubuntu)
 Importance: Undecided
 Status: New

** Information type changed from Private Security to Public Security

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu-keyring in Ubuntu.
https://bugs.launchpad.net/bugs/1786471

Title:
  remove 1024D keys from ubuntu-keyring on older LTS

Status in ubuntu-keyring package in Ubuntu:
  New

Bug description:
  Zesty and later (LP: #1363482) are no longer shipping with 1024D keys
  but older LTS releases (Trusty/Xenial) still trust those weak keys:

  $ lsb_release -sc
  xenial

  $ apt-key list
  /etc/apt/trusted.gpg
  
  pub   1024D/437D05B5 2004-09-12
  uid  Ubuntu Archive Automatic Signing Key 

  sub   2048g/79164387 2004-09-12

  pub   4096R/C0B21F32 2012-05-11
  uid  Ubuntu Archive Automatic Signing Key (2012) 


  pub   4096R/EFE21092 2012-05-11
  uid  Ubuntu CD Image Automatic Signing Key (2012) 


  pub   1024D/FBB75451 2004-12-30
  uid  Ubuntu CD Image Automatic Signing Key 


  
  On Xenial, I found no problem after deleting the 2 1024D keys:

  $ sudo apt-key del 2A38B3EB
  $ sudo apt-key del 437D05B5
  $ sudo apt-get -qq update
  $ echo $? # returned 0

  
  On Trusty, it seems that removing the key 437D05B5 leads to warnings due to 
the double-signing:

  $ sudo apt-key del 2A38B3EB
  $ sudo apt-key del 437D05B5
  $ sudo apt-get -qq update
  W: There is no public key available for the following key IDs:
  40976EAF437D05B5
  W: There is no public key available for the following key IDs:
  40976EAF437D05B5
  W: There is no public key available for the following key IDs:
  40976EAF437D05B5
  $ echo $? # returned 0

  It seems that "apt-get update" is still happy as it can validate using
  the stronger key.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-keyring/+bug/1786471/+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 1750051] Re: cron doesn't support MAILFROM

2018-05-07 Thread Simon Déziel
I looked at the patch (didn't test it) and I think the fprintf call is
missing an argument to format as a string. It should read like this
IMHO:

-   fprintf(mail, "From: root (Cron Daemon)\n");
+   fprintf(mail, "From: %s\n", mailfrom);

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to cron in Ubuntu.
https://bugs.launchpad.net/bugs/1750051

Title:
  cron doesn't support MAILFROM

Status in cron package in Ubuntu:
  Triaged
Status in cron package in Debian:
  New

Bug description:
  Ubuntu's cron version doesn't support setting MAILFROM to set the
  "From:" header of cron generated emails. This feature would be nice to
  have and bring parity with RHEL/CentOS which has it since RHEL 6:

  $ cat /etc/redhat-release 
  CentOS release 6.6 (Final)

  $ man 5 crontab | grep -1 FROM
 doesn´t do aliasing, and UUCP usually doesn´t read its mail.  If  MAIL-
 FROM is defined (and non-empty), it will be used as the envelope sender
 address, otherwise, ‘‘root’’ will be used.

  $ apt-cache policy cron
  cron:
Installed: 3.0pl1-128ubuntu2
Candidate: 3.0pl1-128ubuntu2
Version table:
   *** 3.0pl1-128ubuntu2 500
  500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
  100 /var/lib/dpkg/status

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: cron 3.0pl1-128ubuntu2
  ProcVersionSignature: Ubuntu 4.4.0-116.140-generic 4.4.98
  Uname: Linux 4.4.0-116-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.1-0ubuntu2.15
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Fri Feb 16 15:52:54 2018
  InstallationDate: Installed on 2016-12-06 (436 days ago)
  InstallationMedia: Ubuntu-Server 16.04.1 LTS "Xenial Xerus" - Beta amd64 
(20161206)
  SourcePackage: cron
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cron/+bug/1750051/+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 1732030] Re: 'apt update' dies with seccomp error

2018-04-17 Thread Simon Déziel
It's already mentioned in the NEWS file but for those who would like to
test the seccomp sanbox, all that's needed is:

  APT::Sandbox::Seccomp "true";

Thanks Julian

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1732030

Title:
  'apt update' dies with seccomp error

Status in apt package in Ubuntu:
  Fix Released
Status in libvirt package in Ubuntu:
  Fix Released

Bug description:
  $ apt-get update
  0% [Working]
    Seccomp prevented execution of syscall 78 on architecture amd64 

  Reading package lists... Done
  E: Method mirror has died unexpectedly!
  E: Sub-process mirror returned an error code (31)

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: apt 1.6~alpha5
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.7-0ubuntu4
  Architecture: amd64
  Date: Mon Nov 13 23:10:57 2017
  ProcEnviron:
   LANGUAGE=en_US:en
   TERM=xterm
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/zsh
  SourcePackage: apt
  UpgradeStatus: Upgraded to bionic on 2017-05-20 (177 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1732030/+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 1751402] [NEW] abstraction/nameservice should include allow access to /var/lib/sss/mc/initgroups

2018-02-23 Thread Simon Déziel
Public bug reported:

From
https://bugs.launchpad.net/ubuntu/+source/unbound/+bug/1749931/comments/4:

[2794367.925181] apparmor="DENIED" operation="open"
profile="/usr/sbin/unbound" name="/var/lib/sss/mc/initgroups" pid=5111
comm="unbound" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

The unbound AA profile includes abstractions/nameservice which already
has some rules for files under /var/lib/sss/mc. I think that adding
"/var/lib/sss/mc/initgroups r" to abstractions/nameservice would make
sense:

$ diff -Naur abstractions/nameservice.orig abstractions/nameservice
--- abstractions/nameservice.orig   2018-02-24 02:19:24.310884300 +
+++ abstractions/nameservice2018-02-24 02:20:10.578785312 +
@@ -30,6 +30,7 @@
   # and the nss plugin also needs to talk to a pipe
   /var/lib/sss/mc/group   r,
   /var/lib/sss/mc/passwd  r,
+  /var/lib/sss/mc/initgroups r,
   /var/lib/sss/pipes/nss  rw,
 
   /etc/resolv.confr,

** Affects: apparmor (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1751402

Title:
  abstraction/nameservice should include allow access to
  /var/lib/sss/mc/initgroups

Status in apparmor package in Ubuntu:
  New

Bug description:
  From
  https://bugs.launchpad.net/ubuntu/+source/unbound/+bug/1749931/comments/4:

  [2794367.925181] apparmor="DENIED" operation="open"
  profile="/usr/sbin/unbound" name="/var/lib/sss/mc/initgroups" pid=5111
  comm="unbound" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

  The unbound AA profile includes abstractions/nameservice which already
  has some rules for files under /var/lib/sss/mc. I think that adding
  "/var/lib/sss/mc/initgroups r" to abstractions/nameservice would make
  sense:

  $ diff -Naur abstractions/nameservice.orig abstractions/nameservice
  --- abstractions/nameservice.orig 2018-02-24 02:19:24.310884300 +
  +++ abstractions/nameservice  2018-02-24 02:20:10.578785312 +
  @@ -30,6 +30,7 @@
 # and the nss plugin also needs to talk to a pipe
 /var/lib/sss/mc/group   r,
 /var/lib/sss/mc/passwd  r,
  +  /var/lib/sss/mc/initgroups r,
 /var/lib/sss/pipes/nss  rw,
   
 /etc/resolv.confr,

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1751402/+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 1750051] [NEW] cron doesn't support MAILFROM

2018-02-16 Thread Simon Déziel
Public bug reported:

Ubuntu's cron version doesn't support setting MAILFROM to set the
"From:" header of cron generated emails. This feature would be nice to
have and bring parity with RHEL/CentOS which has it since RHEL 6:

$ cat /etc/redhat-release 
CentOS release 6.6 (Final)

$ man 5 crontab | grep -1 FROM
   doesn´t do aliasing, and UUCP usually doesn´t read its mail.  If  MAIL-
   FROM is defined (and non-empty), it will be used as the envelope sender
   address, otherwise, ‘‘root’’ will be used.

$ apt-cache policy cron
cron:
  Installed: 3.0pl1-128ubuntu2
  Candidate: 3.0pl1-128ubuntu2
  Version table:
 *** 3.0pl1-128ubuntu2 500
500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
100 /var/lib/dpkg/status

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: cron 3.0pl1-128ubuntu2
ProcVersionSignature: Ubuntu 4.4.0-116.140-generic 4.4.98
Uname: Linux 4.4.0-116-generic x86_64
NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
ApportVersion: 2.20.1-0ubuntu2.15
Architecture: amd64
CurrentDesktop: Unity
Date: Fri Feb 16 15:52:54 2018
InstallationDate: Installed on 2016-12-06 (436 days ago)
InstallationMedia: Ubuntu-Server 16.04.1 LTS "Xenial Xerus" - Beta amd64 
(20161206)
SourcePackage: cron
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: cron (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug xenial

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to cron in Ubuntu.
https://bugs.launchpad.net/bugs/1750051

Title:
  cron doesn't support MAILFROM

Status in cron package in Ubuntu:
  New

Bug description:
  Ubuntu's cron version doesn't support setting MAILFROM to set the
  "From:" header of cron generated emails. This feature would be nice to
  have and bring parity with RHEL/CentOS which has it since RHEL 6:

  $ cat /etc/redhat-release 
  CentOS release 6.6 (Final)

  $ man 5 crontab | grep -1 FROM
 doesn´t do aliasing, and UUCP usually doesn´t read its mail.  If  MAIL-
 FROM is defined (and non-empty), it will be used as the envelope sender
 address, otherwise, ‘‘root’’ will be used.

  $ apt-cache policy cron
  cron:
Installed: 3.0pl1-128ubuntu2
Candidate: 3.0pl1-128ubuntu2
Version table:
   *** 3.0pl1-128ubuntu2 500
  500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
  100 /var/lib/dpkg/status

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: cron 3.0pl1-128ubuntu2
  ProcVersionSignature: Ubuntu 4.4.0-116.140-generic 4.4.98
  Uname: Linux 4.4.0-116-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.1-0ubuntu2.15
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Fri Feb 16 15:52:54 2018
  InstallationDate: Installed on 2016-12-06 (436 days ago)
  InstallationMedia: Ubuntu-Server 16.04.1 LTS "Xenial Xerus" - Beta amd64 
(20161206)
  SourcePackage: cron
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cron/+bug/1750051/+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 1553137] Re: Change in OpenSSL triggers bug in XMLTooling

2018-01-17 Thread Simon Déziel
Xenial ships 1.5.6-2 so marking as fix released.

** Changed in: xmltooling (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1553137

Title:
  Change in OpenSSL triggers bug in XMLTooling

Status in openssl package in Ubuntu:
  New
Status in xmltooling package in Ubuntu:
  Fix Released

Bug description:
  A recent change in the openssl package provided by Ubuntu triggers a
  bug in xmltooling. The change was introduced in openssl 1.0.1f-
  1ubuntu2.17 (14.04) and 1.0.1-4ubuntu5.34 (12.04) when releasing for
  USN-2913-3 [1]. Patch alt-cert-chains-7.patch (found in [2,3]) changes
  the intended use of the OpenSSL API and xmltooling was using it
  wrongly. This is fixed in upstream xmltooling version 1.5.6 [4].
  Please backport the fix from 1.5.6 or upgrade the xmltooling package
  to 1.5.6.

  [1] http://www.ubuntu.com/usn/usn-2913-3/
  [2] 
https://launchpadlibrarian.net/236983031/openssl_1.0.1-4ubuntu5.33_1.0.1-4ubuntu5.34.diff.gz
  [3] 
https://launchpadlibrarian.net/236982637/openssl_1.0.1f-1ubuntu2.16_1.0.1f-1ubuntu2.17.diff.gz
  [4] https://issues.shibboleth.net/jira/browse/CPPXT-105

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: libxmltooling6 (not installed)
  ProcVersionSignature: Ubuntu 3.13.0-79.123-generic 3.13.11-ckt33
  Uname: Linux 3.13.0-79-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3.19
  Architecture: amd64
  CurrentDesktop: MATE
  Date: Fri Mar  4 11:43:47 2016
  InstallationDate: Installed on 2015-02-04 (394 days ago)
  InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 
(20140722.2)
  SourcePackage: xmltooling
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1553137/+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 1737998] Re: trying to bind on all interfaces is a good default, but fails on ipv6 link local

2017-12-13 Thread Simon Déziel
On a hypervisor, binding on link local IPs is undesirable IMHO and
that's why I always added a similar ignore to the one you proposed. That
said, NTP works well over link local addresses so some folks are
probably using it.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ntp in Ubuntu.
https://bugs.launchpad.net/bugs/1737998

Title:
  trying to bind on all interfaces is a good default, but fails on ipv6
  link local

Status in ntp package in Ubuntu:
  Incomplete

Bug description:
  The default is "grab all" which is great for convenience and can be
  configured to be differently by argument -I (interface) or interface
  commands in the config.

  Currently it is "too" open on that.
  I see it trying to bing link local addresses for each of the KVM guests I 
spawn.
  They get virtual network devices and due to that ntp sees it tries to bind 
and fails.

 Dez 13 11:35:41 seidel ntpd[35826]: bind(31) AF_INET6 
fe80::fc54:ff:fec3:3eb0%47#123 flags 0x11 failed: Cannot assign requested 
address
 Dez 13 11:35:41 seidel ntpd[35826]: unable to create socket on vnet0 (27) 
for fe80::fc54:ff:fec3:3eb0%47#123
 Dez 13 11:35:41 seidel ntpd[35826]: failed to init interface for address 
fe80::fc54:ff:fec3:3eb0%47

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1737998/+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


Re: [Touch-packages] [Bug 1737377] Re: Unknown tunnel mode "vti6"

2017-12-11 Thread Simon Déziel
Hello Christian,

On 2017-12-11 10:36 AM, ChristianEhrhardt wrote:
> Hi Simon,
> we are currently shuffling around responsibilities for iproute so extra 
> latencies might occur :-/.

I have no urgent need for this. I was simply experimenting with an
IPv6-only lab.

> 2. the Xenial kernel has this type disabled.
> If throwing in an HWE kernel [1] into xenial, does it then work for you?

The required module (ip6_vti) is in 4.4. Loading it and strace'ing the
ip link I got this:

socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, NETLINK_ROUTE) = 3
setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0
setsockopt(3, SOL_SOCKET, SO_RCVBUF, [1048576], 4) = 0
bind(3, {sa_family=AF_NETLINK, pid=0, groups=}, 12) = 0
getsockname(3, {sa_family=AF_NETLINK, pid=1194, groups=}, [12]) = 0
write(2, ""..., 27Unknown tunnel mode "vti6"
) = 27
exit_group(-1)  = ?

I get the same on 4.13.0-19-generic from linux-image-virtual-
hwe-16.04-edge.

> 1. the iproute package needs fixes that came later than what is in Xenial:
> The package needs to be very close to the kernel version in general.
> Did you have any chance to test the newer 4.9 by forcing it into a Xenial 
> system if that works as well? If you need a ppa for that let me know and I'll 
> create one for you.

As a quick and dirty test, I installed Zesty's debs of iproute2 and
libelf1 on Xenial and that worked with both kernel 4.4 and 4.13.

Thanks,
Simon

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iproute2 in Ubuntu.
https://bugs.launchpad.net/bugs/1737377

Title:
  Unknown tunnel mode "vti6"

Status in iproute2 package in Ubuntu:
  New

Bug description:
  [Impact]

  Xenial users are unable to create vti6 tunnels.

  [Test case]

  1) Create a vti6 tunnel
   sudo ip tunnel add vti0 mode vti6 local :: remote fdd6:bdb4:5614::2 key 54
  2) No error should be displayed and "ip link" should show a new device named 
"vti0"

  The ip tunnel call currently fails with the error 'Unknown tunnel mode
  "vti6"' and no tunnel is created.

  [Other Info]

  vti6 mode is supported according to the man page:

  $ man ip-tunnel | grep vti6
 MODE :=  { ipip | gre | sit | isatap | vti | ip6ip6 | ipip6 | ip6gre | 
vti6 | any }
   Modes for IPv6 encapsulation available: ip6ip6, ipip6, 
ip6gre, vti6, and any.

  iproute2 4.9.0-1ubuntu2 on *Artful* has no problem creating vti6
  tunnels.

  $ lsb_release -rd
  Description:  Ubuntu 16.04.3 LTS
  Release:  16.04
  $ apt-cache policy iproute2
  iproute2:
Installed: 4.3.0-1ubuntu3.16.04.3
Candidate: 4.3.0-1ubuntu3.16.04.3
Version table:
   *** 4.3.0-1ubuntu3.16.04.3 500
  500 http://archive.ubuntu.com/ubuntu xenial-proposed/main amd64 
Packages
  100 /var/lib/dpkg/status
   4.3.0-1ubuntu3.16.04.2 500
  500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
   4.3.0-1ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: iproute2 4.3.0-1ubuntu3.16.04.3
  ProcVersionSignature: Ubuntu 4.4.0-103.126-generic 4.4.98
  Uname: Linux 4.4.0-103-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.1-0ubuntu2.14
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Sat Dec  9 21:55:27 2017
  InstallationDate: Installed on 2016-12-06 (368 days ago)
  InstallationMedia: Ubuntu-Server 16.04.1 LTS "Xenial Xerus" - Beta amd64 
(20161206)
  SourcePackage: iproute2
  UpgradeStatus: No upgrade log present (probably fresh install)
  modified.conffile..etc.iproute2.rt_tables: [modified]
  mtime.conffile..etc.iproute2.rt_tables: 2016-12-21T17:41:32.869321

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1737377/+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 1737377] [NEW] Unknown tunnel mode "vti6"

2017-12-09 Thread Simon Déziel
Public bug reported:

[Impact]

Xenial users are unable to create vti6 tunnels.

[Test case]

1) Create a vti6 tunnel
 sudo ip tunnel add vti0 mode vti6 local :: remote fdd6:bdb4:5614::2 key 54
2) No error should be displayed and "ip link" should show a new device named 
"vti0"

The ip tunnel call currently fails with the error 'Unknown tunnel mode
"vti6"' and no tunnel is created.

[Other Info]

vti6 mode is supported according to the man page:

$ man ip-tunnel | grep vti6
   MODE :=  { ipip | gre | sit | isatap | vti | ip6ip6 | ipip6 | ip6gre | 
vti6 | any }
 Modes for IPv6 encapsulation available: ip6ip6, ipip6, 
ip6gre, vti6, and any.

iproute2 4.9.0-1ubuntu2 on *Artful* has no problem creating vti6
tunnels.

$ lsb_release -rd
Description:Ubuntu 16.04.3 LTS
Release:16.04
$ apt-cache policy iproute2
iproute2:
  Installed: 4.3.0-1ubuntu3.16.04.3
  Candidate: 4.3.0-1ubuntu3.16.04.3
  Version table:
 *** 4.3.0-1ubuntu3.16.04.3 500
500 http://archive.ubuntu.com/ubuntu xenial-proposed/main amd64 Packages
100 /var/lib/dpkg/status
 4.3.0-1ubuntu3.16.04.2 500
500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
 4.3.0-1ubuntu3 500
500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: iproute2 4.3.0-1ubuntu3.16.04.3
ProcVersionSignature: Ubuntu 4.4.0-103.126-generic 4.4.98
Uname: Linux 4.4.0-103-generic x86_64
NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
ApportVersion: 2.20.1-0ubuntu2.14
Architecture: amd64
CurrentDesktop: Unity
Date: Sat Dec  9 21:55:27 2017
InstallationDate: Installed on 2016-12-06 (368 days ago)
InstallationMedia: Ubuntu-Server 16.04.1 LTS "Xenial Xerus" - Beta amd64 
(20161206)
SourcePackage: iproute2
UpgradeStatus: No upgrade log present (probably fresh install)
modified.conffile..etc.iproute2.rt_tables: [modified]
mtime.conffile..etc.iproute2.rt_tables: 2016-12-21T17:41:32.869321

** Affects: iproute2 (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug package-from-proposed xenial

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iproute2 in Ubuntu.
https://bugs.launchpad.net/bugs/1737377

Title:
  Unknown tunnel mode "vti6"

Status in iproute2 package in Ubuntu:
  New

Bug description:
  [Impact]

  Xenial users are unable to create vti6 tunnels.

  [Test case]

  1) Create a vti6 tunnel
   sudo ip tunnel add vti0 mode vti6 local :: remote fdd6:bdb4:5614::2 key 54
  2) No error should be displayed and "ip link" should show a new device named 
"vti0"

  The ip tunnel call currently fails with the error 'Unknown tunnel mode
  "vti6"' and no tunnel is created.

  [Other Info]

  vti6 mode is supported according to the man page:

  $ man ip-tunnel | grep vti6
 MODE :=  { ipip | gre | sit | isatap | vti | ip6ip6 | ipip6 | ip6gre | 
vti6 | any }
   Modes for IPv6 encapsulation available: ip6ip6, ipip6, 
ip6gre, vti6, and any.

  iproute2 4.9.0-1ubuntu2 on *Artful* has no problem creating vti6
  tunnels.

  $ lsb_release -rd
  Description:  Ubuntu 16.04.3 LTS
  Release:  16.04
  $ apt-cache policy iproute2
  iproute2:
Installed: 4.3.0-1ubuntu3.16.04.3
Candidate: 4.3.0-1ubuntu3.16.04.3
Version table:
   *** 4.3.0-1ubuntu3.16.04.3 500
  500 http://archive.ubuntu.com/ubuntu xenial-proposed/main amd64 
Packages
  100 /var/lib/dpkg/status
   4.3.0-1ubuntu3.16.04.2 500
  500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
   4.3.0-1ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: iproute2 4.3.0-1ubuntu3.16.04.3
  ProcVersionSignature: Ubuntu 4.4.0-103.126-generic 4.4.98
  Uname: Linux 4.4.0-103-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.1-0ubuntu2.14
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Sat Dec  9 21:55:27 2017
  InstallationDate: Installed on 2016-12-06 (368 days ago)
  InstallationMedia: Ubuntu-Server 16.04.1 LTS "Xenial Xerus" - Beta amd64 
(20161206)
  SourcePackage: iproute2
  UpgradeStatus: No upgrade log present (probably fresh install)
  modified.conffile..etc.iproute2.rt_tables: [modified]
  mtime.conffile..etc.iproute2.rt_tables: 2016-12-21T17:41:32.869321

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1737377/+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 1689585] Re: ntp doesn't unload its apparmor profile on purge

2017-11-23 Thread Simon Déziel
Thanks for the patch Christian, I relayed it in https://bugs.debian.org
/cgi-bin/bugreport.cgi?bug=882556

** Bug watch added: Debian Bug tracker #882556
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882556

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1689585

Title:
  ntp doesn't unload its apparmor profile on purge

Status in apparmor package in Ubuntu:
  Won't Fix
Status in ntp package in Ubuntu:
  Confirmed

Bug description:
  Steps to reproduce:

  1) install ntp
apt install ntp
  2) confirm it has loaded its AA profile
aa-status | grep ntpd
  3) purge ntp
apt purge ntp
  4) the profile is left behind but shouldn't
aa-status | grep ntpd


  Additional info:

  This was found by first install ntp then changing my mind and deciding to go 
with OpenNTPD.
  FYI, just installing openntpd while ntp is still there works because openntpd 
has a kludge
  to unload ntpd's profile but that only works if the ntp package wasn't purged 
before.

   /var/lib/dpkg/info/openntpd.preinst:
   if [ -f /etc/apparmor.d/usr.sbin.ntpd ] && pathfind apparmor_parser ; then
   apparmor_parser -R /etc/apparmor.d/usr.sbin.ntpd
   fi
   
  Since a purge deletes /etc/apparmor.d/usr.sbin.ntpd, openntpd.preinst's 
kludge is ineffective.
  In any case, having implementation B include workaround for implementation A 
not cleaning up
  after itself seems wrong and the issue should be fixed at the source IMHO.

  # lsb_release -rd
  Description:  Ubuntu 16.04.2 LTS
  Release:  16.04
  # apt-cache policy ntp
  ntp:
Installed: 1:4.2.8p4+dfsg-3ubuntu5.4
Candidate: 1:4.2.8p4+dfsg-3ubuntu5.4
Version table:
   *** 1:4.2.8p4+dfsg-3ubuntu5.4 500
  500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   1:4.2.8p4+dfsg-3ubuntu5.3 500
  500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 
Packages
   1:4.2.8p4+dfsg-3ubuntu5 500
  500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: ntp (not installed)
  ProcVersionSignature: Ubuntu 4.4.0-78.99-generic 4.4.62
  Uname: Linux 4.4.0-78-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.5
  Architecture: amd64
  Date: Tue May  9 15:48:42 2017
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   LANG=en_US.UTF-8
  SourcePackage: ntp
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1689585/+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 1689833] Re: OpenVPN server does not start properly on boot

2017-11-20 Thread Simon Déziel
A possible workaround would be to add "Restart=on-failure" in the
"[Service]" section of the systemd unit.

-- 
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/1689833

Title:
  OpenVPN server does not start properly on boot

Status in openvpn package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  New

Bug description:
  OpenVPN intermittently fails to bind to local address during boot on
  Ubuntu Server 16.04.2 LTS. Sometimes it succeeds, sometimes it does
  not.

  /var/log/openvpn.log
  Wed May 10 15:42:02 2017 OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] 
[LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Feb  2 2016
  Wed May 10 15:42:02 2017 library versions: OpenSSL 1.0.2g  1 Mar 2016, LZO 
2.08
  Wed May 10 15:42:02 2017 Diffie-Hellman initialized with 2048 bit key
  Wed May 10 15:42:02 2017 Control Channel Authentication: using 
'./easy-rsa/keys/ta.key' as a OpenVPN static key file
  Wed May 10 15:42:02 2017 Outgoing Control Channel Authentication: Using 160 
bit message hash 'SHA1' for HMAC authentication
  Wed May 10 15:42:02 2017 Incoming Control Channel Authentication: Using 160 
bit message hash 'SHA1' for HMAC authentication
  Wed May 10 15:42:02 2017 Socket Buffers: R=[212992->212992] S=[212992->212992]
  Wed May 10 15:42:02 2017 TCP/UDP: Socket bind failed on local address 
[AF_INET]192.168.4.254:1194: Cannot assign requested address
  Wed May 10 15:42:02 2017 Exiting due to fatal error

  In case it does not start, running 'sudo service openvpn start' fixes
  that problem.

  /var/log/openvpn.log
  Wed May 10 15:42:43 2017 OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] 
[LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Feb  2 2016
  Wed May 10 15:42:43 2017 library versions: OpenSSL 1.0.2g  1 Mar 2016, LZO 
2.08
  Wed May 10 15:42:43 2017 Diffie-Hellman initialized with 2048 bit key
  Wed May 10 15:42:43 2017 Control Channel Authentication: using 
'./easy-rsa/keys/ta.key' as a OpenVPN static key file
  Wed May 10 15:42:43 2017 Outgoing Control Channel Authentication: Using 160 
bit message hash 'SHA1' for HMAC authentication
  Wed May 10 15:42:43 2017 Incoming Control Channel Authentication: Using 160 
bit message hash 'SHA1' for HMAC authentication
  Wed May 10 15:42:43 2017 Socket Buffers: R=[212992->212992] S=[212992->212992]
  Wed May 10 15:42:43 2017 ROUTE_GATEWAY 192.168.4.1/255.255.255.0 IFACE=ens4 
HWADDR=52:54:00:f0:26:0c
  Wed May 10 15:42:43 2017 TUN/TAP device tun0 opened
  Wed May 10 15:42:43 2017 TUN/TAP TX queue length set to 100
  Wed May 10 15:42:43 2017 do_ifconfig, tt->ipv6=0, 
tt->did_ifconfig_ipv6_setup=0
  Wed May 10 15:42:43 2017 /sbin/ip link set dev tun0 up mtu 1500
  Wed May 10 15:42:43 2017 /sbin/ip addr add dev tun0 local 172.16.1.1 peer 
172.16.1.2
  Wed May 10 15:42:43 2017 /sbin/ip route add 172.16.1.0/24 via 172.16.1.2
  Wed May 10 15:42:43 2017 GID set to nogroup
  Wed May 10 15:42:43 2017 UID set to nobody
  Wed May 10 15:42:43 2017 UDPv4 link local (bound): [AF_INET]192.168.4.254:1194
  Wed May 10 15:42:43 2017 UDPv4 link remote: [undef]
  Wed May 10 15:42:43 2017 MULTI: multi_init called, r=256 v=256
  Wed May 10 15:42:43 2017 IFCONFIG POOL: base=172.16.1.4 size=62, ipv6=0
  Wed May 10 15:42:43 2017 IFCONFIG POOL LIST
  Wed May 10 15:42:43 2017 Initialization Sequence Completed

  My guess is that systemd starts OpenVPN too early before the network
  is brought up sufficiently. Running 'sudo systemctl edit --full
  openvpn' and adding 'Wants=network-online.target' does not change that
  behaviour.

  user@server:~$ sudo systemd-analyze critical-chain
  graphical.target @2.160s
  └─multi-user.target @2.159s
    └─ntp.service @2.054s +104ms
  └─remote-fs.target @2.052s
    └─remote-fs-pre.target @2.052s
  └─open-iscsi.service @1.993s +57ms
    └─iscsid.service @1.942s +47ms
  └─network-online.target @1.941s
    └─network.target @1.929s
  └─networking.service @1.793s +134ms
    └─apparmor.service @1.140s +395ms
  └─local-fs.target @1.140s
    └─local-fs-pre.target @1.139s
  └─lvm2-monitor.service @602ms +536ms
    └─lvm2-lvmetad.service @773ms
  └─systemd-journald.socket @574ms
    └─-.slice @500ms

  The boot time is quite short. Clean install with the additional
  packages ntp and openssh-server. This happens both on bare metal and
  as a Virtual Machine (KVM) as well.

  /etc/openvpn/server.conf
  local 192.168.4.254
  port 1194
  proto udp
  dev tun
  ca ./easy-rsa/keys/ca.crt
  cert ./easy-rsa/keys/crt.crt
  key ./easy-rsa/keys/key.key
  dh ./easy-rsa/keys/dh2048.pem
  tls-auth ./easy-rsa/keys/ta.key 0
  server 172.16.1.0 255.255.255.0
  ifconfig-pool-persist ipp.txt
  push "route 192.168.0.0 

[Touch-packages] [Bug 1042771] Re: sanitized_helper prevents proper transition to other profiles

2017-10-27 Thread Simon Déziel
Maybe a fallback mechanism would be needed? Something like this:

  /usr/bin/evince (Px, Cxr -> sanitized_helper),

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1042771

Title:
  sanitized_helper prevents proper transition to other profiles

Status in apparmor package in Ubuntu:
  Confirmed

Bug description:
  When an application using the sanitized_helper launches another binary
  also covered by another apparmor profile, the launched binary is
  running with the sanitized_helper profile instead of transiting. Here
  is way to reproduce/observe the problem:

  Launch firefox to open a PDF through Evince:
  1) firefox https://help.ubuntu.com/10.04/serverguide/serverguide.pdf

  Observe the Apparmor profiles loaded:
  2) ps Zaux| grep -v ^unconfined
  /usr/lib/firefox/firefox{,*[^s][^h]} simon 19556 33.1  2.1 773068 168052 
pts/5 Sl+  10:11   0:03 /usr/lib/firefox/firefox 
https://help.ubuntu.com/10.04/serverguide/serverguide.pdf
  /usr/lib/firefox/firefox{,*[^s][^h]}//sanitized_helper simon 19586 19.6  0.4 
561964 37176 pts/5 Sl+ 10:11   0:00 evince /tmp/serverguide.pdf

  I would expect Evince to run with its own profile like it does
  normally:

  3) evince /tmp/serverguide.pdf
  4) ps Zaux| grep -v ^unconfined
  /usr/bin/evince simon20218 12.7  0.4 560240 35124 pts/5   
 Sl+  10:22   0:00 evince /tmp/serverguide.pdf

  $ lsb_release -rd
  Description:  Ubuntu 12.04.1 LTS
  Release:  12.04

  $ apt-cache policy apparmor firefox evince
  apparmor:
    Installed: 2.7.102-0ubuntu3.1
    Candidate: 2.7.102-0ubuntu3.1
    Version table:
   *** 2.7.102-0ubuntu3.1 0
  500 http://archive.ubuntu.com/ubuntu/ precise-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu/ precise-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   2.7.102-0ubuntu3 0
  500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
  firefox:
    Installed: 14.0.1+build1-0ubuntu0.12.04.3
    Candidate: 14.0.1+build1-0ubuntu0.12.04.3
    Version table:
   *** 14.0.1+build1-0ubuntu0.12.04.3 0
  500 http://archive.ubuntu.com/ubuntu/ precise-proposed/main amd64 
Packages
  100 /var/lib/dpkg/status
   14.0.1+build1-0ubuntu0.12.04.1 0
  500 http://archive.ubuntu.com/ubuntu/ precise-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu/ precise-security/main amd64 
Packages
   11.0+build1-0ubuntu4 0
  500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
  evince:
    Installed: 3.4.0-0ubuntu1.3
    Candidate: 3.4.0-0ubuntu1.3
    Version table:
   *** 3.4.0-0ubuntu1.3 0
  500 http://archive.ubuntu.com/ubuntu/ precise-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   3.4.0-0ubuntu1 0
  500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages

  ProblemType: Bug
  DistroRelease: Ubuntu 12.04
  Package: apparmor 2.7.102-0ubuntu3.1
  ProcVersionSignature: Ubuntu 3.2.0-30.48-generic 3.2.27
  Uname: Linux 3.2.0-30-generic x86_64
  ApportVersion: 2.0.1-0ubuntu12
  Architecture: amd64
  Date: Tue Aug 28 10:12:30 2012
  ProcEnviron:
   LANGUAGE=en_CA:en
   TERM=xterm
   PATH=(custom, no user)
   LANG=en_CA.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdline: BOOT_IMAGE=/vmlinuz-3.2.0-30-generic 
root=/dev/mapper/crypt-root ro quiet splash i915.i915_enable_fbc=1 
i915.lvds_downclock=1 drm.vblankoffdelay=1 vt.handoff=7
  SourcePackage: apparmor
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1042771/+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 1042771] Re: sanitized_helper prevents proper transition to other profiles

2017-10-26 Thread Simon Déziel
Since Evince ships with an Apparmor profile on its own, I think the
following fix makes sense:

$ diff -Naur abstractions/ubuntu-browsers.d/productivity{.orig,}
--- abstractions/ubuntu-browsers.d/productivity.orig2017-10-26 
15:34:03.374102924 -0400
+++ abstractions/ubuntu-browsers.d/productivity 2017-10-26 15:33:55.398235488 
-0400
@@ -20,7 +20,7 @@
   /usr/lib/libreoffice/program/soffice Cxr -> sanitized_helper,
 
   # PDFs
-  /usr/bin/evince Cxr -> sanitized_helper,
+  /usr/bin/evince Px,
   /usr/bin/okular Cxr -> sanitized_helper,
 
   owner @{HOME}/.adobe/** rw,

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1042771

Title:
  sanitized_helper prevents proper transition to other profiles

Status in apparmor package in Ubuntu:
  Confirmed

Bug description:
  When an application using the sanitized_helper launches another binary
  also covered by another apparmor profile, the launched binary is
  running with the sanitized_helper profile instead of transiting. Here
  is way to reproduce/observe the problem:

  Launch firefox to open a PDF through Evince:
  1) firefox https://help.ubuntu.com/10.04/serverguide/serverguide.pdf

  Observe the Apparmor profiles loaded:
  2) ps Zaux| grep -v ^unconfined
  /usr/lib/firefox/firefox{,*[^s][^h]} simon 19556 33.1  2.1 773068 168052 
pts/5 Sl+  10:11   0:03 /usr/lib/firefox/firefox 
https://help.ubuntu.com/10.04/serverguide/serverguide.pdf
  /usr/lib/firefox/firefox{,*[^s][^h]}//sanitized_helper simon 19586 19.6  0.4 
561964 37176 pts/5 Sl+ 10:11   0:00 evince /tmp/serverguide.pdf

  I would expect Evince to run with its own profile like it does
  normally:

  3) evince /tmp/serverguide.pdf
  4) ps Zaux| grep -v ^unconfined
  /usr/bin/evince simon20218 12.7  0.4 560240 35124 pts/5   
 Sl+  10:22   0:00 evince /tmp/serverguide.pdf

  $ lsb_release -rd
  Description:  Ubuntu 12.04.1 LTS
  Release:  12.04

  $ apt-cache policy apparmor firefox evince
  apparmor:
    Installed: 2.7.102-0ubuntu3.1
    Candidate: 2.7.102-0ubuntu3.1
    Version table:
   *** 2.7.102-0ubuntu3.1 0
  500 http://archive.ubuntu.com/ubuntu/ precise-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu/ precise-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   2.7.102-0ubuntu3 0
  500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
  firefox:
    Installed: 14.0.1+build1-0ubuntu0.12.04.3
    Candidate: 14.0.1+build1-0ubuntu0.12.04.3
    Version table:
   *** 14.0.1+build1-0ubuntu0.12.04.3 0
  500 http://archive.ubuntu.com/ubuntu/ precise-proposed/main amd64 
Packages
  100 /var/lib/dpkg/status
   14.0.1+build1-0ubuntu0.12.04.1 0
  500 http://archive.ubuntu.com/ubuntu/ precise-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu/ precise-security/main amd64 
Packages
   11.0+build1-0ubuntu4 0
  500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
  evince:
    Installed: 3.4.0-0ubuntu1.3
    Candidate: 3.4.0-0ubuntu1.3
    Version table:
   *** 3.4.0-0ubuntu1.3 0
  500 http://archive.ubuntu.com/ubuntu/ precise-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   3.4.0-0ubuntu1 0
  500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages

  ProblemType: Bug
  DistroRelease: Ubuntu 12.04
  Package: apparmor 2.7.102-0ubuntu3.1
  ProcVersionSignature: Ubuntu 3.2.0-30.48-generic 3.2.27
  Uname: Linux 3.2.0-30-generic x86_64
  ApportVersion: 2.0.1-0ubuntu12
  Architecture: amd64
  Date: Tue Aug 28 10:12:30 2012
  ProcEnviron:
   LANGUAGE=en_CA:en
   TERM=xterm
   PATH=(custom, no user)
   LANG=en_CA.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdline: BOOT_IMAGE=/vmlinuz-3.2.0-30-generic 
root=/dev/mapper/crypt-root ro quiet splash i915.i915_enable_fbc=1 
i915.lvds_downclock=1 drm.vblankoffdelay=1 vt.handoff=7
  SourcePackage: apparmor
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1042771/+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 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer

2017-09-08 Thread Simon Déziel
I see the NM one passes now, thanks for retrying it. The aria2 armhf
problem reliably fails though. I guess I'll have to setup a QEMU VM for
that arch and manually run the test to see what's going on.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnutls26 in Ubuntu.
https://bugs.launchpad.net/bugs/1709193

Title:
  Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer

Status in gnutls26 package in Ubuntu:
  Invalid
Status in gnutls28 package in Ubuntu:
  Fix Released
Status in gnutls26 source package in Trusty:
  Fix Committed
Status in gnutls28 source package in Trusty:
  Won't Fix
Status in ssmtp source package in Trusty:
  Invalid
Status in gnutls26 source package in Xenial:
  Invalid
Status in gnutls28 source package in Xenial:
  Fix Committed
Status in ssmtp source package in Xenial:
  Invalid
Status in gnutls26 source package in Zesty:
  Invalid
Status in gnutls28 source package in Zesty:
  Fix Released
Status in ssmtp source package in Zesty:
  Invalid
Status in gnutls26 source package in Artful:
  Invalid
Status in gnutls28 source package in Artful:
  Fix Released
Status in ssmtp source package in Artful:
  Invalid
Status in gnutls28 package in Debian:
  Fix Released

Bug description:
  [Impact]

  Applications using GnuTLS OpenSSL compat layer [1] are be unable to
  use modern TLS versions (1.1 and 1.2) when relying on the
  SSLv23_{client,server}_method functions.

  There is an industry-wide push to use modern TLS versions, see [2] and
  [3] for example.

  The proposed fix changes the compat layer to use GnuTLS' "NORMAL"
  priority [4] instead of hard-coding which protocol versions and
  ciphers to enable.

  [Test Case]

  1) Setup a mail submission server that uses StartTLS
  2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay
 through the mail relay using StartTLS
  3) Send an email while capturing with tcpdump/tshark
  4) Inspect the submission connection (TCP/587) and look for the protocol
 version negotiated by the client.

  Without the fix, you should see TLSv1.0. With the fix, it should be
  TLSv1.2.

  Please see the original issue description for more details.

  [Regression Potential]

  Regression risk should be low since it's a backport of a simple fix
  that landed in Debian in April 2017.

  [References]

  1: $ apt-cache rdepends libgnutls-openssl27
  libgnutls-openssl27
  Reverse Depends:
libgnutls-dev
libgnutls-dev
zoneminder
yaskkserv
tf5
ssmtp
snowdrop
sngrep
slrnpull
slrn
sipsak
macopix-gtk2
gnss-sdr
gkrellm
freewheeling
boinctui
iputils-ping

  2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html
  3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls
  4: https://gnutls.org/manual/html_node/Priority-Strings.html

  
  [Original issue description]

  sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with
  it. Here's a packet capture when ssmtp connects to
  smtp.sdeziel.info:587 that offers TLSv1.0 and higher:

  $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | 
grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)'
  Version: TLS 1.0 (0x0301)
  Handshake Protocol: Client Hello
  Version: TLS 1.0 (0x0301)
  Cipher Suites Length: 30
  Cipher Suites (15 suites)
  Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
  Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
  Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
  Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
  Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
  Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
  Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
  Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045)
  Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088)
  Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
  Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
  Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
  Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044)
  Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087)
  Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)

  I would expect ssmtp to use TLSv1.2 and a recent cipher like the
  openssl s_client is able to do:

  $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 
2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)'
  Protocol  : TLSv1.2
  Cipher: ECDHE-RSA-AES128-GCM-SHA256

  Additional information:

  $ lsb_release -rd
  Description:  Ubuntu 16.04.3 LTS
  Release:  16.04
  $ apt-cache 

[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer

2017-09-08 Thread Simon Déziel
@juliank, thanks for the update. I wasn't aware of the autopkgtest
failing for some reverse dependencies. Any pointers to those? I'm
determined to see this one though, but on Monday ;)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnutls26 in Ubuntu.
https://bugs.launchpad.net/bugs/1709193

Title:
  Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer

Status in gnutls26 package in Ubuntu:
  Invalid
Status in gnutls28 package in Ubuntu:
  Fix Released
Status in gnutls26 source package in Trusty:
  Fix Committed
Status in gnutls28 source package in Trusty:
  Won't Fix
Status in ssmtp source package in Trusty:
  Invalid
Status in gnutls26 source package in Xenial:
  Invalid
Status in gnutls28 source package in Xenial:
  Fix Committed
Status in ssmtp source package in Xenial:
  Invalid
Status in gnutls26 source package in Zesty:
  Invalid
Status in gnutls28 source package in Zesty:
  Fix Released
Status in ssmtp source package in Zesty:
  Invalid
Status in gnutls26 source package in Artful:
  Invalid
Status in gnutls28 source package in Artful:
  Fix Released
Status in ssmtp source package in Artful:
  Invalid
Status in gnutls28 package in Debian:
  Fix Released

Bug description:
  [Impact]

  Applications using GnuTLS OpenSSL compat layer [1] are be unable to
  use modern TLS versions (1.1 and 1.2) when relying on the
  SSLv23_{client,server}_method functions.

  There is an industry-wide push to use modern TLS versions, see [2] and
  [3] for example.

  The proposed fix changes the compat layer to use GnuTLS' "NORMAL"
  priority [4] instead of hard-coding which protocol versions and
  ciphers to enable.

  [Test Case]

  1) Setup a mail submission server that uses StartTLS
  2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay
 through the mail relay using StartTLS
  3) Send an email while capturing with tcpdump/tshark
  4) Inspect the submission connection (TCP/587) and look for the protocol
 version negotiated by the client.

  Without the fix, you should see TLSv1.0. With the fix, it should be
  TLSv1.2.

  Please see the original issue description for more details.

  [Regression Potential]

  Regression risk should be low since it's a backport of a simple fix
  that landed in Debian in April 2017.

  [References]

  1: $ apt-cache rdepends libgnutls-openssl27
  libgnutls-openssl27
  Reverse Depends:
libgnutls-dev
libgnutls-dev
zoneminder
yaskkserv
tf5
ssmtp
snowdrop
sngrep
slrnpull
slrn
sipsak
macopix-gtk2
gnss-sdr
gkrellm
freewheeling
boinctui
iputils-ping

  2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html
  3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls
  4: https://gnutls.org/manual/html_node/Priority-Strings.html

  
  [Original issue description]

  sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with
  it. Here's a packet capture when ssmtp connects to
  smtp.sdeziel.info:587 that offers TLSv1.0 and higher:

  $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | 
grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)'
  Version: TLS 1.0 (0x0301)
  Handshake Protocol: Client Hello
  Version: TLS 1.0 (0x0301)
  Cipher Suites Length: 30
  Cipher Suites (15 suites)
  Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
  Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
  Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
  Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
  Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
  Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
  Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
  Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045)
  Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088)
  Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
  Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
  Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
  Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044)
  Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087)
  Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)

  I would expect ssmtp to use TLSv1.2 and a recent cipher like the
  openssl s_client is able to do:

  $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 
2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)'
  Protocol  : TLSv1.2
  Cipher: ECDHE-RSA-AES128-GCM-SHA256

  Additional information:

  $ lsb_release -rd
  Description:  Ubuntu 16.04.3 LTS
  Release:  16.04
  $ apt-cache policy ssmtp 

[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer

2017-09-08 Thread Simon Déziel
The Xenial fix is identical to what went in Artful and Zesty so it
shouldn't be subject to any more review.

The review was requested to check if the different fix proposed for
Trusty was OK.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnutls26 in Ubuntu.
https://bugs.launchpad.net/bugs/1709193

Title:
  Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer

Status in gnutls26 package in Ubuntu:
  Invalid
Status in gnutls28 package in Ubuntu:
  Fix Released
Status in gnutls26 source package in Trusty:
  Fix Committed
Status in gnutls28 source package in Trusty:
  Won't Fix
Status in ssmtp source package in Trusty:
  Invalid
Status in gnutls26 source package in Xenial:
  Invalid
Status in gnutls28 source package in Xenial:
  Fix Committed
Status in ssmtp source package in Xenial:
  Invalid
Status in gnutls26 source package in Zesty:
  Invalid
Status in gnutls28 source package in Zesty:
  Fix Released
Status in ssmtp source package in Zesty:
  Invalid
Status in gnutls26 source package in Artful:
  Invalid
Status in gnutls28 source package in Artful:
  Fix Released
Status in ssmtp source package in Artful:
  Invalid
Status in gnutls28 package in Debian:
  Fix Released

Bug description:
  [Impact]

  Applications using GnuTLS OpenSSL compat layer [1] are be unable to
  use modern TLS versions (1.1 and 1.2) when relying on the
  SSLv23_{client,server}_method functions.

  There is an industry-wide push to use modern TLS versions, see [2] and
  [3] for example.

  The proposed fix changes the compat layer to use GnuTLS' "NORMAL"
  priority [4] instead of hard-coding which protocol versions and
  ciphers to enable.

  [Test Case]

  1) Setup a mail submission server that uses StartTLS
  2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay
 through the mail relay using StartTLS
  3) Send an email while capturing with tcpdump/tshark
  4) Inspect the submission connection (TCP/587) and look for the protocol
 version negotiated by the client.

  Without the fix, you should see TLSv1.0. With the fix, it should be
  TLSv1.2.

  Please see the original issue description for more details.

  [Regression Potential]

  Regression risk should be low since it's a backport of a simple fix
  that landed in Debian in April 2017.

  [References]

  1: $ apt-cache rdepends libgnutls-openssl27
  libgnutls-openssl27
  Reverse Depends:
libgnutls-dev
libgnutls-dev
zoneminder
yaskkserv
tf5
ssmtp
snowdrop
sngrep
slrnpull
slrn
sipsak
macopix-gtk2
gnss-sdr
gkrellm
freewheeling
boinctui
iputils-ping

  2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html
  3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls
  4: https://gnutls.org/manual/html_node/Priority-Strings.html

  
  [Original issue description]

  sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with
  it. Here's a packet capture when ssmtp connects to
  smtp.sdeziel.info:587 that offers TLSv1.0 and higher:

  $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | 
grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)'
  Version: TLS 1.0 (0x0301)
  Handshake Protocol: Client Hello
  Version: TLS 1.0 (0x0301)
  Cipher Suites Length: 30
  Cipher Suites (15 suites)
  Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
  Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
  Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
  Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
  Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
  Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
  Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
  Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045)
  Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088)
  Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
  Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
  Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
  Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044)
  Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087)
  Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)

  I would expect ssmtp to use TLSv1.2 and a recent cipher like the
  openssl s_client is able to do:

  $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 
2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)'
  Protocol  : TLSv1.2
  Cipher: ECDHE-RSA-AES128-GCM-SHA256

  Additional information:

  $ lsb_release -rd
  Description:  Ubuntu 16.04.3 LTS
  Release:  16.04
  $ apt-cache policy 

[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer

2017-09-08 Thread Simon Déziel
It's been a while since the Xenial -proposed package have been
successfully validated. Is there anything preventing it from entering
-updates?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnutls26 in Ubuntu.
https://bugs.launchpad.net/bugs/1709193

Title:
  Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer

Status in gnutls26 package in Ubuntu:
  Invalid
Status in gnutls28 package in Ubuntu:
  Fix Released
Status in gnutls26 source package in Trusty:
  Fix Committed
Status in gnutls28 source package in Trusty:
  Won't Fix
Status in ssmtp source package in Trusty:
  Invalid
Status in gnutls26 source package in Xenial:
  Invalid
Status in gnutls28 source package in Xenial:
  Fix Committed
Status in ssmtp source package in Xenial:
  Invalid
Status in gnutls26 source package in Zesty:
  Invalid
Status in gnutls28 source package in Zesty:
  Fix Released
Status in ssmtp source package in Zesty:
  Invalid
Status in gnutls26 source package in Artful:
  Invalid
Status in gnutls28 source package in Artful:
  Fix Released
Status in ssmtp source package in Artful:
  Invalid
Status in gnutls28 package in Debian:
  Fix Released

Bug description:
  [Impact]

  Applications using GnuTLS OpenSSL compat layer [1] are be unable to
  use modern TLS versions (1.1 and 1.2) when relying on the
  SSLv23_{client,server}_method functions.

  There is an industry-wide push to use modern TLS versions, see [2] and
  [3] for example.

  The proposed fix changes the compat layer to use GnuTLS' "NORMAL"
  priority [4] instead of hard-coding which protocol versions and
  ciphers to enable.

  [Test Case]

  1) Setup a mail submission server that uses StartTLS
  2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay
 through the mail relay using StartTLS
  3) Send an email while capturing with tcpdump/tshark
  4) Inspect the submission connection (TCP/587) and look for the protocol
 version negotiated by the client.

  Without the fix, you should see TLSv1.0. With the fix, it should be
  TLSv1.2.

  Please see the original issue description for more details.

  [Regression Potential]

  Regression risk should be low since it's a backport of a simple fix
  that landed in Debian in April 2017.

  [References]

  1: $ apt-cache rdepends libgnutls-openssl27
  libgnutls-openssl27
  Reverse Depends:
libgnutls-dev
libgnutls-dev
zoneminder
yaskkserv
tf5
ssmtp
snowdrop
sngrep
slrnpull
slrn
sipsak
macopix-gtk2
gnss-sdr
gkrellm
freewheeling
boinctui
iputils-ping

  2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html
  3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls
  4: https://gnutls.org/manual/html_node/Priority-Strings.html

  
  [Original issue description]

  sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with
  it. Here's a packet capture when ssmtp connects to
  smtp.sdeziel.info:587 that offers TLSv1.0 and higher:

  $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | 
grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)'
  Version: TLS 1.0 (0x0301)
  Handshake Protocol: Client Hello
  Version: TLS 1.0 (0x0301)
  Cipher Suites Length: 30
  Cipher Suites (15 suites)
  Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
  Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
  Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
  Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
  Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
  Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
  Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
  Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045)
  Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088)
  Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
  Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
  Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
  Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044)
  Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087)
  Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)

  I would expect ssmtp to use TLSv1.2 and a recent cipher like the
  openssl s_client is able to do:

  $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 
2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)'
  Protocol  : TLSv1.2
  Cipher: ECDHE-RSA-AES128-GCM-SHA256

  Additional information:

  $ lsb_release -rd
  Description:  Ubuntu 16.04.3 LTS
  Release:  16.04
  $ apt-cache policy ssmtp libgnutls-openssl27
  ssmtp:
    Installed: 

[Touch-packages] [Bug 624361] Re: service ssh restart does not test the configuration file

2017-08-23 Thread Simon Déziel
** Bug watch added: Debian Bug tracker #865770
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865770

** Also affects: openssh (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865770
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/624361

Title:
  service ssh restart does not test the configuration file

Status in openssh package in Ubuntu:
  Triaged
Status in openssh package in Debian:
  Unknown

Bug description:
  I would have expect "service ssh restart" to run the configuration
  test as "/etc/init.d/ssh restart" do. Or at least, I would have expect
  to have a meaningful exit status in case of failure.

  I modified "/etc/ssh/sshd_config" and mistakenly inserted an error. I
  tried to apply my modification by restarting SSH :

  # service ssh restart
  ssh start/running

  # echo $?
  0

  Because no error were reported I assumed that SSH was running with the
  new configuration. I was wrong because SSH never restarted because of
  a the syntax error in /etc/ssh/sshd_config.

  After some digging I found the error :

  # service ssh try-restart
  /etc/ssh/sshd_config line 100: Directive 'AllowUsers' is not allowed within a 
Match block

  Am I wrong to expecting that the new starting method provided in Lucid
  ("service  ") is equivalent to the old technique
  involving an init script ?

  # lsb_release -rd
  Description:  Ubuntu 10.04.1 LTS
  Release:  10.04

  # apt-cache policy openssh-server
  openssh-server:
Installed: 1:5.3p1-3ubuntu4
Candidate: 1:5.3p1-3ubuntu4
Version table:
   *** 1:5.3p1-3ubuntu4 0
  500 http://ca.archive.ubuntu.com/ubuntu/ lucid-updates/main Packages
  100 /var/lib/dpkg/status
   1:5.3p1-3ubuntu3 0
  500 http://ca.archive.ubuntu.com/ubuntu/ lucid/main Packages

  ProblemType: Bug
  DistroRelease: Ubuntu 10.04
  Package: openssh-server 1:5.3p1-3ubuntu4
  ProcVersionSignature: Ubuntu 2.6.32-24.41-generic 2.6.32.15+drm33.5
  Uname: Linux 2.6.32-24-generic x86_64
  Architecture: amd64
  Date: Wed Aug 25 20:56:54 2010
  ProcEnviron:
   LANG=en_US.UTF8
   SHELL=/bin/bash
  SourcePackage: openssh

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/624361/+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 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer

2017-08-21 Thread Simon Déziel
On Truty with 2.12.23-12ubuntu2.9, the sSMTP client would abort the
StartTLS connection complaining it didn't support the signature
algorithm in use.

When validating I used a mail relay with a RSA-SHA256 cert signed by
CAcert.org. CAcert.org is (self-signed) RSA-MD5. It turned out that
Trusty also needed the GnuTLS priority string to include
%VERIFY_ALLOW_SIGN_RSA_MD5 to support that use case and avoid the
regression. It's unclear to me why only gnutls26 needed this since I
used the exact same test case for all 3 distro versions.

The version 2 of the debdiff for Trusty was tested with certificates
chains including MD5, SHA1 and SHA256 certificates and revealed no
problem and fixed the regression previously found.

** Patch added: "lp1709193-14.04-version2.debdiff"
   
https://bugs.launchpad.net/debian/+source/gnutls28/+bug/1709193/+attachment/4936464/+files/lp1709193-14.04-version2.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnutls26 in Ubuntu.
https://bugs.launchpad.net/bugs/1709193

Title:
  Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer

Status in gnutls26 package in Ubuntu:
  Invalid
Status in gnutls28 package in Ubuntu:
  Fix Released
Status in gnutls26 source package in Trusty:
  Fix Committed
Status in gnutls28 source package in Trusty:
  Won't Fix
Status in ssmtp source package in Trusty:
  Invalid
Status in gnutls26 source package in Xenial:
  Invalid
Status in gnutls28 source package in Xenial:
  Fix Committed
Status in ssmtp source package in Xenial:
  Invalid
Status in gnutls26 source package in Zesty:
  Invalid
Status in gnutls28 source package in Zesty:
  Fix Committed
Status in ssmtp source package in Zesty:
  Invalid
Status in gnutls26 source package in Artful:
  Invalid
Status in gnutls28 source package in Artful:
  Fix Released
Status in ssmtp source package in Artful:
  Invalid
Status in gnutls28 package in Debian:
  Fix Released

Bug description:
  [Impact]

  Applications using GnuTLS OpenSSL compat layer [1] are be unable to
  use modern TLS versions (1.1 and 1.2) when relying on the
  SSLv23_{client,server}_method functions.

  There is an industry-wide push to use modern TLS versions, see [2] and
  [3] for example.

  The proposed fix changes the compat layer to use GnuTLS' "NORMAL"
  priority [4] instead of hard-coding which protocol versions and
  ciphers to enable.

  [Test Case]

  1) Setup a mail submission server that uses StartTLS
  2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay
 through the mail relay using StartTLS
  3) Send an email while capturing with tcpdump/tshark
  4) Inspect the submission connection (TCP/587) and look for the protocol
 version negotiated by the client.

  Without the fix, you should see TLSv1.0. With the fix, it should be
  TLSv1.2.

  Please see the original issue description for more details.

  [Regression Potential]

  Regression risk should be low since it's a backport of a simple fix
  that landed in Debian in April 2017.

  [References]

  1: $ apt-cache rdepends libgnutls-openssl27
  libgnutls-openssl27
  Reverse Depends:
libgnutls-dev
libgnutls-dev
zoneminder
yaskkserv
tf5
ssmtp
snowdrop
sngrep
slrnpull
slrn
sipsak
macopix-gtk2
gnss-sdr
gkrellm
freewheeling
boinctui
iputils-ping

  2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html
  3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls
  4: https://gnutls.org/manual/html_node/Priority-Strings.html

  
  [Original issue description]

  sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with
  it. Here's a packet capture when ssmtp connects to
  smtp.sdeziel.info:587 that offers TLSv1.0 and higher:

  $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | 
grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)'
  Version: TLS 1.0 (0x0301)
  Handshake Protocol: Client Hello
  Version: TLS 1.0 (0x0301)
  Cipher Suites Length: 30
  Cipher Suites (15 suites)
  Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
  Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
  Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
  Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
  Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
  Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
  Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
  Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045)
  Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088)
  Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
  Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
  Cipher 

[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer

2017-08-18 Thread Simon Déziel
The trusty-proposed version (2.12.23-12ubuntu2.9) doesn't work and
introduces a regression preventing successful TLS/SSL connections. I'll
check if there is an easy fix for gnutls26.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnutls26 in Ubuntu.
https://bugs.launchpad.net/bugs/1709193

Title:
  Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer

Status in gnutls26 package in Ubuntu:
  Invalid
Status in gnutls28 package in Ubuntu:
  Fix Released
Status in gnutls26 source package in Trusty:
  Fix Committed
Status in gnutls28 source package in Trusty:
  Won't Fix
Status in ssmtp source package in Trusty:
  Invalid
Status in gnutls26 source package in Xenial:
  Invalid
Status in gnutls28 source package in Xenial:
  Fix Committed
Status in ssmtp source package in Xenial:
  Invalid
Status in gnutls26 source package in Zesty:
  Invalid
Status in gnutls28 source package in Zesty:
  Fix Committed
Status in ssmtp source package in Zesty:
  Invalid
Status in gnutls26 source package in Artful:
  Invalid
Status in gnutls28 source package in Artful:
  Fix Released
Status in ssmtp source package in Artful:
  Invalid
Status in gnutls28 package in Debian:
  Fix Released

Bug description:
  [Impact]

  Applications using GnuTLS OpenSSL compat layer [1] are be unable to
  use modern TLS versions (1.1 and 1.2) when relying on the
  SSLv23_{client,server}_method functions.

  There is an industry-wide push to use modern TLS versions, see [2] and
  [3] for example.

  The proposed fix changes the compat layer to use GnuTLS' "NORMAL"
  priority [4] instead of hard-coding which protocol versions and
  ciphers to enable.

  [Test Case]

  1) Setup a mail submission server that uses StartTLS
  2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay
 through the mail relay using StartTLS
  3) Send an email while capturing with tcpdump/tshark
  4) Inspect the submission connection (TCP/587) and look for the protocol
 version negotiated by the client.

  Without the fix, you should see TLSv1.0. With the fix, it should be
  TLSv1.2.

  Please see the original issue description for more details.

  [Regression Potential]

  Regression risk should be low since it's a backport of a simple fix
  that landed in Debian in April 2017.

  [References]

  1: $ apt-cache rdepends libgnutls-openssl27
  libgnutls-openssl27
  Reverse Depends:
libgnutls-dev
libgnutls-dev
zoneminder
yaskkserv
tf5
ssmtp
snowdrop
sngrep
slrnpull
slrn
sipsak
macopix-gtk2
gnss-sdr
gkrellm
freewheeling
boinctui
iputils-ping

  2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html
  3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls
  4: https://gnutls.org/manual/html_node/Priority-Strings.html

  
  [Original issue description]

  sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with
  it. Here's a packet capture when ssmtp connects to
  smtp.sdeziel.info:587 that offers TLSv1.0 and higher:

  $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | 
grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)'
  Version: TLS 1.0 (0x0301)
  Handshake Protocol: Client Hello
  Version: TLS 1.0 (0x0301)
  Cipher Suites Length: 30
  Cipher Suites (15 suites)
  Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
  Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
  Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
  Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
  Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
  Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
  Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
  Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045)
  Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088)
  Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
  Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
  Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
  Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044)
  Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087)
  Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)

  I would expect ssmtp to use TLSv1.2 and a recent cipher like the
  openssl s_client is able to do:

  $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 
2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)'
  Protocol  : TLSv1.2
  Cipher: ECDHE-RSA-AES128-GCM-SHA256

  Additional information:

  $ lsb_release -rd
  Description:  Ubuntu 16.04.3 LTS
  Release:  16.04
  $ apt-cache policy ssmtp 

[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer

2017-08-18 Thread Simon Déziel
Verified on Zesty with:

$ apt-cache policy libgnutls-openssl27:amd64
libgnutls-openssl27:
  Installed: 3.5.6-4ubuntu4.2
  Candidate: 3.5.6-4ubuntu4.2
  Version table:
 *** 3.5.6-4ubuntu4.2 500
500 http://archive.ubuntu.com/ubuntu zesty-proposed/main amd64 Packages
100 /var/lib/dpkg/status
 3.5.6-4ubuntu4.1 500
500 http://archive.ubuntu.com/ubuntu zesty-updates/main amd64 Packages
500 http://security.ubuntu.com/ubuntu zesty-security/main amd64 Packages
 3.5.6-4ubuntu4 500
500 http://archive.ubuntu.com/ubuntu zesty/main amd64 Packages

** Tags removed: verification-done-xenial verification-needed-zesty
** Tags added: verification-done-zesty verification-needed-xenial

** Tags removed: verification-needed-trusty verification-needed-xenial
** Tags added: verification-done-xenial verification-failed-trusty

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnutls26 in Ubuntu.
https://bugs.launchpad.net/bugs/1709193

Title:
  Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer

Status in gnutls26 package in Ubuntu:
  Invalid
Status in gnutls28 package in Ubuntu:
  Fix Released
Status in gnutls26 source package in Trusty:
  Fix Committed
Status in gnutls28 source package in Trusty:
  Won't Fix
Status in ssmtp source package in Trusty:
  Invalid
Status in gnutls26 source package in Xenial:
  Invalid
Status in gnutls28 source package in Xenial:
  Fix Committed
Status in ssmtp source package in Xenial:
  Invalid
Status in gnutls26 source package in Zesty:
  Invalid
Status in gnutls28 source package in Zesty:
  Fix Committed
Status in ssmtp source package in Zesty:
  Invalid
Status in gnutls26 source package in Artful:
  Invalid
Status in gnutls28 source package in Artful:
  Fix Released
Status in ssmtp source package in Artful:
  Invalid
Status in gnutls28 package in Debian:
  Fix Released

Bug description:
  [Impact]

  Applications using GnuTLS OpenSSL compat layer [1] are be unable to
  use modern TLS versions (1.1 and 1.2) when relying on the
  SSLv23_{client,server}_method functions.

  There is an industry-wide push to use modern TLS versions, see [2] and
  [3] for example.

  The proposed fix changes the compat layer to use GnuTLS' "NORMAL"
  priority [4] instead of hard-coding which protocol versions and
  ciphers to enable.

  [Test Case]

  1) Setup a mail submission server that uses StartTLS
  2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay
 through the mail relay using StartTLS
  3) Send an email while capturing with tcpdump/tshark
  4) Inspect the submission connection (TCP/587) and look for the protocol
 version negotiated by the client.

  Without the fix, you should see TLSv1.0. With the fix, it should be
  TLSv1.2.

  Please see the original issue description for more details.

  [Regression Potential]

  Regression risk should be low since it's a backport of a simple fix
  that landed in Debian in April 2017.

  [References]

  1: $ apt-cache rdepends libgnutls-openssl27
  libgnutls-openssl27
  Reverse Depends:
libgnutls-dev
libgnutls-dev
zoneminder
yaskkserv
tf5
ssmtp
snowdrop
sngrep
slrnpull
slrn
sipsak
macopix-gtk2
gnss-sdr
gkrellm
freewheeling
boinctui
iputils-ping

  2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html
  3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls
  4: https://gnutls.org/manual/html_node/Priority-Strings.html

  
  [Original issue description]

  sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with
  it. Here's a packet capture when ssmtp connects to
  smtp.sdeziel.info:587 that offers TLSv1.0 and higher:

  $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | 
grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)'
  Version: TLS 1.0 (0x0301)
  Handshake Protocol: Client Hello
  Version: TLS 1.0 (0x0301)
  Cipher Suites Length: 30
  Cipher Suites (15 suites)
  Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
  Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
  Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
  Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
  Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
  Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
  Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
  Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045)
  Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088)
  Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
  Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
  Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA 

[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer

2017-08-18 Thread Simon Déziel
Verified on Xenial with:

$ apt-cache policy libgnutls-openssl27:amd64
libgnutls-openssl27:
  Installed: 3.4.10-4ubuntu1.4
  Candidate: 3.4.10-4ubuntu1.4
  Version table:
 *** 3.4.10-4ubuntu1.4 500
500 http://archive.ubuntu.com/ubuntu xenial-proposed/main amd64 Packages
100 /var/lib/dpkg/status
 3.4.10-4ubuntu1.3 500
500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 
Packages
 3.4.10-4ubuntu1 500
500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages

** Tags removed: verification-needed-xenial
** Tags added: verification-done-xenial

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnutls26 in Ubuntu.
https://bugs.launchpad.net/bugs/1709193

Title:
  Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer

Status in gnutls26 package in Ubuntu:
  Invalid
Status in gnutls28 package in Ubuntu:
  Fix Released
Status in gnutls26 source package in Trusty:
  Fix Committed
Status in gnutls28 source package in Trusty:
  Won't Fix
Status in ssmtp source package in Trusty:
  Invalid
Status in gnutls26 source package in Xenial:
  Invalid
Status in gnutls28 source package in Xenial:
  Fix Committed
Status in ssmtp source package in Xenial:
  Invalid
Status in gnutls26 source package in Zesty:
  Invalid
Status in gnutls28 source package in Zesty:
  Fix Committed
Status in ssmtp source package in Zesty:
  Invalid
Status in gnutls26 source package in Artful:
  Invalid
Status in gnutls28 source package in Artful:
  Fix Released
Status in ssmtp source package in Artful:
  Invalid
Status in gnutls28 package in Debian:
  Fix Released

Bug description:
  [Impact]

  Applications using GnuTLS OpenSSL compat layer [1] are be unable to
  use modern TLS versions (1.1 and 1.2) when relying on the
  SSLv23_{client,server}_method functions.

  There is an industry-wide push to use modern TLS versions, see [2] and
  [3] for example.

  The proposed fix changes the compat layer to use GnuTLS' "NORMAL"
  priority [4] instead of hard-coding which protocol versions and
  ciphers to enable.

  [Test Case]

  1) Setup a mail submission server that uses StartTLS
  2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay
 through the mail relay using StartTLS
  3) Send an email while capturing with tcpdump/tshark
  4) Inspect the submission connection (TCP/587) and look for the protocol
 version negotiated by the client.

  Without the fix, you should see TLSv1.0. With the fix, it should be
  TLSv1.2.

  Please see the original issue description for more details.

  [Regression Potential]

  Regression risk should be low since it's a backport of a simple fix
  that landed in Debian in April 2017.

  [References]

  1: $ apt-cache rdepends libgnutls-openssl27
  libgnutls-openssl27
  Reverse Depends:
libgnutls-dev
libgnutls-dev
zoneminder
yaskkserv
tf5
ssmtp
snowdrop
sngrep
slrnpull
slrn
sipsak
macopix-gtk2
gnss-sdr
gkrellm
freewheeling
boinctui
iputils-ping

  2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html
  3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls
  4: https://gnutls.org/manual/html_node/Priority-Strings.html

  
  [Original issue description]

  sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with
  it. Here's a packet capture when ssmtp connects to
  smtp.sdeziel.info:587 that offers TLSv1.0 and higher:

  $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | 
grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)'
  Version: TLS 1.0 (0x0301)
  Handshake Protocol: Client Hello
  Version: TLS 1.0 (0x0301)
  Cipher Suites Length: 30
  Cipher Suites (15 suites)
  Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
  Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
  Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
  Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
  Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
  Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
  Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
  Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045)
  Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088)
  Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
  Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
  Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
  Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044)
  Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087)
   

[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer

2017-08-11 Thread Simon Déziel
** Description changed:

+ [Impact]
+ 
+ Applications using GnuTLS OpenSSL compat layer [1] are be unable to use
+ modern TLS versions (1.1 and 1.2) when relying on the
+ SSLv23_{client,server}_method functions.
+ 
+ There is an industry-wide push to use modern TLS versions, see [2] and
+ [3] for example.
+ 
+ The proposed fix changes the compat layer to use GnuTLS' "NORMAL"
+ priority [4] instead of hard-coding which protocol versions and ciphers
+ to enable.
+ 
+ [Test Case]
+ 
+ 1) Setup a mail submission server that uses StartTLS
+ 2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay
+through the mail relay using StartTLS
+ 3) Send an email while capturing with tcpdump/tshark
+ 4) Inspect the submission connection (TCP/587) and look for the protocol
+version negotiated by the client.
+ 
+ Without the fix, you should see TLSv1.0. With the fix, it should be
+ TLSv1.2.
+ 
+ Please see the original issue description for more details.
+ 
+ [Regression Potential]
+ 
+ Regression risk should be low since it's a backport of a simple fix that
+ landed in Debian in April 2017.
+ 
+ [References]
+ 
+ 1: $ apt-cache rdepends libgnutls-openssl27
+ libgnutls-openssl27
+ Reverse Depends:
+   libgnutls-dev
+   libgnutls-dev
+   zoneminder
+   yaskkserv
+   tf5
+   ssmtp
+   snowdrop
+   sngrep
+   slrnpull
+   slrn
+   sipsak
+   macopix-gtk2
+   gnss-sdr
+   gkrellm
+   freewheeling
+   boinctui
+   iputils-ping
+   
+ 2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html
+ 3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls
+ 4: https://gnutls.org/manual/html_node/Priority-Strings.html
+ 
+ 
+ [Original issue description]
+ 
  sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with
  it. Here's a packet capture when ssmtp connects to smtp.sdeziel.info:587
  that offers TLSv1.0 and higher:
  
  $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | 
grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)'
- Version: TLS 1.0 (0x0301)
- Handshake Protocol: Client Hello
- Version: TLS 1.0 (0x0301)
- Cipher Suites Length: 30
- Cipher Suites (15 suites)
- Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
- Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
- Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
- Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
- Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
- Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
- Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
- Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045)
- Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088)
- Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
- Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
- Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
- Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044)
- Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087)
- Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
+ Version: TLS 1.0 (0x0301)
+ Handshake Protocol: Client Hello
+ Version: TLS 1.0 (0x0301)
+ Cipher Suites Length: 30
+ Cipher Suites (15 suites)
+ Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
+ Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
+ Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
+ Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
+ Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
+ Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
+ Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
+ Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045)
+ Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088)
+ Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
+ Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
+ Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
+ Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044)
+ Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087)
+ Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
  
  I would expect ssmtp to use TLSv1.2 and a recent cipher like the openssl
  s_client is able to do:
  
  $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 
2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)'
- Protocol  : TLSv1.2
- Cipher: ECDHE-RSA-AES128-GCM-SHA256
- 
+ Protocol  : TLSv1.2

  1   2   3   >