[Touch-packages] [Bug 1933117] Re: ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule

2021-09-18 Thread Jamie Strandboge
** Also affects: ufw (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: ufw (Ubuntu)
   Status: New => In Progress

** Changed in: ufw (Ubuntu)
 Assignee: (unassigned) => Jamie Strandboge (jdstrand)

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

Title:
  ufw delete can confuse protocol-specific rule with otherwise matching
  'proto any' rule

Status in ufw:
  Fix Released
Status in ufw package in Ubuntu:
  In Progress

Bug description:
  UFW versions 0.35 (on Ubuntu 16.04 LTS) and 0.36 (on Ubuntu 20.04 LTS)

  If a rule is inserted without specifying the protocol, it will default
  to both udp and tcp. If a second rule is inserted earlier in the order
  that specifies the protocol but is otherwise identical, UFW will
  delete the wrong rule if the first rule is deleted.

  This is repeatable with the following script:

  ufw insert 1 allow from 1.1.1.1/26 to any port 22
  ufw insert 2 allow from 1.2.3.4/26 to any port 22
  ufw insert 1 allow from 1.2.3.4/26 to any port 22 proto tcp
  iptables -L -n | grep -A 6 "Chain ufw-user-input"
  yes | ufw delete 3
  iptables -L -n | grep -A 4 "Chain ufw-user-input"

  The output is as follows:

  Chain ufw-user-input (1 references)
  target prot opt source   destination
  ACCEPT tcp  --  1.2.3.0/26   0.0.0.0/0tcp dpt:22
  ACCEPT tcp  --  1.1.1.0/26   0.0.0.0/0tcp dpt:22
  ACCEPT udp  --  1.1.1.0/26   0.0.0.0/0udp dpt:22
  ACCEPT tcp  --  1.2.3.0/26   0.0.0.0/0tcp dpt:22
  ACCEPT udp  --  1.2.3.0/26   0.0.0.0/0udp dpt:22

  Chain ufw-user-input (1 references)
  target prot opt source   destination
  ACCEPT tcp  --  1.1.1.0/26   0.0.0.0/0tcp dpt:22
  ACCEPT udp  --  1.1.1.0/26   0.0.0.0/0udp dpt:22
  ACCEPT tcp  --  1.2.3.0/26   0.0.0.0/0tcp dpt:22

  UFW deleted the first rule for 1.2.3.0 and then the last rule for
  1.2.3.0, leaving the wrong rule remaining. Here is the ufw status:

  To Action  From
  -- --  
  22/tcp ALLOW   1.2.3.0/26
  22 ALLOW   1.1.1.0/26

  Mixing ALLOW and REJECT/DENY rules can further result in incorrect
  behavior due to this incorrect reordering. On port 22, this could
  render SSH remotely inaccessible.

  For example, if one had initially set up the following rule to port 22
  (TCP and UDP)...

  ufw insert 1 allow from 1.2.3.4 to any port 22

  ...and later wanted to further restrict it to only TCP, while
  explicitly rejecting any other port 22 connections...

  ufw insert 1 allow from 1.2.3.4 to any port 22 proto tcp
  ufw insert 2 reject from any to any port 22
  yes | ufw delete 3

  ...this would result in SSH becoming inaccessible.

  Instead if one had the initial configuration...

  ufw insert 1 reject from 1.0.0.0/8 to any port 22
  ufw insert 2 allow from any to any port 22

  ...which was later updated to be...

  ufw insert 1 reject from 1.0.0.0/8 to any port 22 proto tcp
  ufw insert 2 allow from any to any port 22 proto tcp
  yes | ufw delete 3

  ...this would result in 1.0.0.0/8 incorrectly being allowed to access
  port 22. While this is a contrived scenario, it is possible and
  reproducible.

  A reboot is required to fix the issue, as it reloads the configuration
  to the expected order.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/1933117/+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 1726856] Re: ufw does not start automatically at boot

2021-09-18 Thread Jamie Strandboge
@cajicas215 - your comment is not helpful. If you look at the other
comments in this bug, there has been nothing to fix in ufw. I suggest
looking at the comments in this bug and seeing if any of the issues
others have seen apply to you. If not, please report a new bug with
steps to reproduce.

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

Title:
  ufw does not start automatically at boot

Status in ufw:
  Invalid
Status in ufw package in Ubuntu:
  Invalid
Status in ufw source package in Xenial:
  Invalid
Status in ufw source package in Bionic:
  Invalid
Status in ufw source package in Cosmic:
  Invalid
Status in ufw source package in Disco:
  Invalid

Bug description:
  Whenever I boot into 17.10 ufw is always inactive, even though
  /etc/ufw/ufw.conf has this:

  # Set to yes to start on boot. If setting this remotely, be sure to add a rule
  # to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp'
  ENABLED=yes

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: ufw 0.35-5
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 24 13:56:40 2017
  InstallationDate: Installed on 2015-04-01 (936 days ago)
  InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 
(20140722.2)
  PackageArchitecture: all
  SourcePackage: ufw
  UpgradeStatus: Upgraded to artful on 2017-10-24 (0 days ago)
  mtime.conffile..etc.default.ufw: 2015-06-17T22:01:02.089170

To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/1726856/+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 1726856] Re: ufw does not start automatically at boot

2021-09-18 Thread Jamie Strandboge
@Fabian - your change both makes the firewall start after networking,
brings python into the boot process (which can slow down boot) and
changes the intent of 'systemctl stop ufw' from unloading the firewall
to disabling the firewall in the moment and forever in the future, which
is inappropriate ('systemctl stop' is supposed to stop the service until
someone runs 'systemctl start' again or reboot. 'systemctl disable' is
meant to prevent the service from starting on reboot. This might be fine
for your system, but it would not be appropriate as a default in ufw or
distributions. Also, this bug is in upstream ufw and you are reporting
an issue on Raspbian, who would supply the packaging for ufw. If you
still feel the change should be made, I suggest filing a bug with
Raspbian so they can change their packaging of ufw.

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

Title:
  ufw does not start automatically at boot

Status in ufw:
  Invalid
Status in ufw package in Ubuntu:
  Invalid
Status in ufw source package in Xenial:
  Invalid
Status in ufw source package in Bionic:
  Invalid
Status in ufw source package in Cosmic:
  Invalid
Status in ufw source package in Disco:
  Invalid

Bug description:
  Whenever I boot into 17.10 ufw is always inactive, even though
  /etc/ufw/ufw.conf has this:

  # Set to yes to start on boot. If setting this remotely, be sure to add a rule
  # to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp'
  ENABLED=yes

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: ufw 0.35-5
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 24 13:56:40 2017
  InstallationDate: Installed on 2015-04-01 (936 days ago)
  InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 
(20140722.2)
  PackageArchitecture: all
  SourcePackage: ufw
  UpgradeStatus: Upgraded to artful on 2017-10-24 (0 days ago)
  mtime.conffile..etc.default.ufw: 2015-06-17T22:01:02.089170

To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/1726856/+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 1934931] Re: (X)ubuntu 20.04: GUFW and MS-Teams slow down traffic intermittently

2021-09-18 Thread Jamie Strandboge
It is unclear from the description that this has anything to do with
networking. Are there any firewall denials in the logs (eg,
/var/log/ufw.log or /var/log/kern.log)? If you disable ufw (sudo ufw
disable) does the problem go away?

As an aside, IIRC, MS-Teams is not a lightweight application and I
suspect this could be memory consumption unrelated to the firewall.

** Changed in: ufw (Ubuntu)
   Status: New => Incomplete

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

Title:
  (X)ubuntu 20.04: GUFW and MS-Teams slow down traffic intermittently

Status in Gufw:
  Invalid
Status in ufw package in Ubuntu:
  Incomplete

Bug description:
  Thanks for Gufw!

  inxi -S output: Xubuntu standard LTS installation - Kernel:
  5.4.0-77-generic x86_64 bits: 64 Desktop: Xfce 4.14.2 Distro: Ubuntu
  20.04.2 LTS (Focal Fossa). GUFW 20.04.1, MS Teams 1.4.00.13653
  (64-Bit) (all up to date at the time of this report).

  ** Problem: 250 Mbit LAN connection slowing down *intermittently*, but 
reproducible, to a crawl of 300 kbit or less if Gufw is activated parallel to 
MS teams. 
  * Gufw is used with only basic settings provided after installation 
(in:denied/out:allowed and nothing else set, no further rules).
  * There has not to be any active call in teams, just running it seems to 
cause the problem after a while (<5 minutes).
  * After congestion for some time (minutes), the system may recover to full 
speed again, only to succumb again after a few minutes. 
  * Other parallel running programs' connections are slowed down as well in 
accordance, e.g. parallel samba file sharing download is affected as well.
  * Stopping teams restores the connection speed after a short while (~1 
minute).
  * Parallel connections to the LAN(router) are not inhibited, it is just the 
one computer. 

  Teams seems to switch ports after restarting (UDP6/~34nnn-4). I
  set up a range to be allowed within ports used by teams (e.g.
  3:5, allow in/outbound) to no avail, connections dropped still
  to low speed.

  Thanks and regards,
  Christoph

To manage notifications about this bug go to:
https://bugs.launchpad.net/gui-ufw/+bug/1934931/+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 1921350] Re: UFW hangs indefinitely on any action

2021-09-18 Thread Jamie Strandboge
There is another bug related to ansible in
https://bugs.launchpad.net/ufw/+bug/1911637. I suggest following that
one. Leaving this one as Expired.

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

Title:
  UFW hangs indefinitely on any action

Status in ufw package in Ubuntu:
  Expired

Bug description:
  When installing a new cloudserver (on Amazon EC2, if it makes a
  difference), UFW completely hangs on any command, for example ufw
  status. Interrupting it with Ctrl+C yields this backtrace:

  Traceback (most recent call last):
File "/usr/sbin/ufw", line 130, in 
  lock = create_lock(lockfile=lockfile, dryrun=pr.dryrun)
File "/usr/lib/python3/dist-packages/ufw/util.py", line 1112, in create_lock
  fcntl.lockf(lock, fcntl.LOCK_EX)
  KeyboardInterrupt

  The line numbers are always the same.

  The platform is Ubuntu Server 20.04 (Ubuntu 20.04.2 LTS), from the
  Amazon image. I have not seen this bug on other servers. UFW is
  version 0.36.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1921350/+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 1909373] Re: package ufw 0.36-0ubuntu0.18.04.1 failed to install/upgrade: installed ufw package post-installation script subprocess returned error exit status 10

2021-09-18 Thread Jamie Strandboge
There isn't anything in the logs the indicates that there what happened.
Do you have any other information?

** Changed in: ufw (Ubuntu)
   Status: New => Incomplete

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

Title:
  package ufw 0.36-0ubuntu0.18.04.1 failed to install/upgrade: installed
  ufw package post-installation script subprocess returned error exit
  status 10

Status in ufw package in Ubuntu:
  Incomplete

Bug description:
  dont upgrade

  ProblemType: Package
  DistroRelease: Ubuntu 18.04
  Package: ufw 0.36-0ubuntu0.18.04.1
  Uname: Linux 3.18.14-17162658-QB35446819 aarch64
  ApportVersion: 2.20.9-0ubuntu7.21
  Architecture: arm64
  Date: Sat Dec 26 20:56:19 2020
  Df:
   Filesystem 1K-blocks Used Available Use% Mounted on
   rootfs  24604780 19261268   5251352  79% /
   tmpfs1434188 1020   1433168   1% /dev
  Dmesg:
   
  ErrorMessage: installed ufw package post-installation script subprocess 
returned error exit status 10
  PackageArchitecture: all
  Python3Details: /usr/bin/python3.6, Python 3.6.5, unpackaged
  PythonDetails: /usr/bin/python2.7, Python 2.7.15rc1, unpackaged
  RelatedPackageVersions:
   dpkg 1.19.0.5ubuntu2
   apt  1.6.1
  SourcePackage: ufw
  Title: package ufw 0.36-0ubuntu0.18.04.1 failed to install/upgrade: installed 
ufw package post-installation script subprocess returned error exit status 10
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1909373/+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 1898696] Re: add some deliminiter between ipv4 and ipv6 in ufw status

2021-09-18 Thread Jamie Strandboge
Thanks you for the report. It is difficult to convey ipv4 vs ipv6 vs
both in list form and currently ufw lists any ipv6 rules  with '(v6)' as
part of the To and From (as seen in your paste). It isn't clear to me
how adding an 'IPv6' break would improve this... I'm going to mark this
as wishlist while I think about it.

Regarding the side note, the person who posted the question was unaware
of https://bugs.launchpad.net/ufw/+bug/1880453 which speaks to future
support (it isn't needed as ufw will use the nft backend if the system
is configured to do so).

** Changed in: ufw (Ubuntu)
   Importance: Undecided => Wishlist

** Changed in: ufw (Ubuntu)
   Status: New => Confirmed

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

Title:
  add some deliminiter between ipv4 and ipv6 in ufw status

Status in ufw package in Ubuntu:
  Confirmed

Bug description:
  "ufw status numbered" shows all the rules in one block, numbered from top to 
bottom. First are the ipv4 rules, then the ipv6.
  This has led to some irritation.

  A user asked how to add a IPv4 rule to the end of the list.
  https://answers.launchpad.net/ubuntu/+source/ufw/+question/692096
  Inserting ipv6 rules to the correct position is not easy to understand
  https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1368411

  My suggestion is to at least add some separator between the ipv4 and ipv6 
rules in the output of "ufw status". A blank line, or a comment line (# IPv6 
rules:) would be fine.
  This would indicate that not both rule lists, but only one of them, is 
applied to a connection.

  ## output suggestion:

  Status: active

   To Action  From
   -- --  
  [ 1] 22/tcp ALLOW INAnywhere  
  [ 2] 8080:8090/tcp  ALLOW INAnywhere   # mywww
  [ 3] WWW Full   ALLOW INAnywhere  
   # IPv6 rules:
  [ 4] 22/tcp (v6)ALLOW INAnywhere (v6) 
  [ 5] 8080:8090/tcp (v6) ALLOW INAnywhere (v6)  # mywww
  [ 6] WWW Full (v6)  ALLOW INAnywhere (v6)

  
  ## system info
  ufw --version: ufw 0.35

   side note
  But maybe this is irrelevant as long as the future plans of ufw are unclear. 
(https://answers.launchpad.net/ubuntu/+source/ufw/+question/692803)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1898696/+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 1911637] Re: Another app is currently holding the xtables lock

2021-09-18 Thread Jamie Strandboge
** Changed in: ufw
   Status: New => Triaged

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

Title:
  Another app is currently holding the xtables lock

Status in ufw:
  Triaged
Status in ufw package in Ubuntu:
  Confirmed
Status in ufw package in Debian:
  New

Bug description:
  Version: ufw 0.36 (via Debian buster 0.36-1 deb-package)

  I'm using ufw together with fail2ban, and often I get an error while
  fail2ban is trying to ban an ip:

  ```
  ERROR: initcaps
  [Errno 2] Another app is currently holding the xtables lock. Perhaps you want 
to use the -w option?

  ```

  it seems that in utils.py, get_netfilter_capabilities(...) iptables is
  called without "-w" flag to wait for the table lock

  perhaps the checks should include this parameter to avoid leaving
  temporary tables behind (and breaking fail2ban, but thats a different
  story ...)?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/1911637/+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 1911637] Re: Another app is currently holding the xtables lock

2021-09-18 Thread Jamie Strandboge
Actually, in thinking about this, ufw could use 'iptables -w' under the
hood. I recall having troubles with this approach when providing the fix
for https://bugs.launchpad.net/ufw/+bug/1204579. I suggest following my
advice in my last comment to avoid the issue while using 'iptables -w'
is explored.

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

Title:
  Another app is currently holding the xtables lock

Status in ufw:
  Triaged
Status in ufw package in Ubuntu:
  Confirmed
Status in ufw package in Debian:
  New

Bug description:
  Version: ufw 0.36 (via Debian buster 0.36-1 deb-package)

  I'm using ufw together with fail2ban, and often I get an error while
  fail2ban is trying to ban an ip:

  ```
  ERROR: initcaps
  [Errno 2] Another app is currently holding the xtables lock. Perhaps you want 
to use the -w option?

  ```

  it seems that in utils.py, get_netfilter_capabilities(...) iptables is
  called without "-w" flag to wait for the table lock

  perhaps the checks should include this parameter to avoid leaving
  temporary tables behind (and breaking fail2ban, but thats a different
  story ...)?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/1911637/+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 1911637] Re: Another app is currently holding the xtables lock

2021-09-18 Thread Jamie Strandboge
Thanks for the report. I read the ansible bug but this issue is actually
coming from the underlying iptables tool. Something on the system is
manipulating the firewall via iptables at the same time that the ufw
command is being run. As described, this would happen with any firewall
software. If only ufw is being used with ansible, perhaps ensure that
the ufw commands are not being run in parallel. The upstream bug
referenced docker, which will also manipulate the firewall with
iptables; perhaps ensure that ufw configuration is applied before docker
is started.

I'm going to mark this bug as Invalid for now. Feel free to provide more
information if you feel this is specific to ufw.

** Changed in: ufw (Ubuntu)
   Status: Confirmed => Invalid

** Changed in: ufw (Ubuntu)
   Status: Invalid => New

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

Title:
  Another app is currently holding the xtables lock

Status in ufw:
  Triaged
Status in ufw package in Ubuntu:
  Confirmed
Status in ufw package in Debian:
  New

Bug description:
  Version: ufw 0.36 (via Debian buster 0.36-1 deb-package)

  I'm using ufw together with fail2ban, and often I get an error while
  fail2ban is trying to ban an ip:

  ```
  ERROR: initcaps
  [Errno 2] Another app is currently holding the xtables lock. Perhaps you want 
to use the -w option?

  ```

  it seems that in utils.py, get_netfilter_capabilities(...) iptables is
  called without "-w" flag to wait for the table lock

  perhaps the checks should include this parameter to avoid leaving
  temporary tables behind (and breaking fail2ban, but thats a different
  story ...)?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/1911637/+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 1938005] Re: ufw ignores rules

2021-08-16 Thread Jamie Strandboge
Recall that ufw uses connection tracking so if you add a deny rule, you
may need to expire the connection tracking. One way to do this is to
run: `conntrack -D -d ` (see man conntrack for details).

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

Title:
  ufw ignores rules

Status in ufw package in Ubuntu:
  Incomplete

Bug description:
  With my setting I shouldn't be able to surf web, but I can do it (without 
proxy/vpn)
  This problem happens after `iptables -F` and only way to solve it, is to 
reboot PC. I tried `ufw reload` , too

  ProblemType: Bug
  DistroRelease: Ubuntu 21.04
  Package: ufw 0.36-7.1
  ProcVersionSignature: Ubuntu 5.11.0-25.27-generic 5.11.22
  Uname: Linux 5.11.0-25-generic x86_64
  ApportVersion: 2.20.11-0ubuntu65.1
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: XFCE
  Date: Mon Jul 26 11:53:17 2021
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2021-06-17 (38 days ago)
  InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420)
  PackageArchitecture: all
  SourcePackage: ufw
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.default.ufw: 2021-07-25T22:22:29.221649

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1938005/+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 1938005] Re: ufw ignores rules

2021-08-07 Thread Jamie Strandboge
/etc/default/ufw has:

DEFAULT_OUTPUT_POLICY="ACCEPT"

This means that all outgoing traffic is allowed. If you would like to
change that, you can use:

$ sudo ufw deny outgoing

This will make it more difficult for you to manage the firewall since
you'll have to add rules like:

$ sudo ufw allow out to any port 53

and the like.

Note, using 'ufw reload' may not work as expected if you are running
iptables commands by hand underneath it. In those case, I suggest:

$ sudo /lib/ufw/ufw-init flush-all
$ sudo ufw disable
$ sudo ufw enable

Please report back. Thanks again for the report.

** Changed in: ufw (Ubuntu)
   Status: New => Incomplete

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

Title:
  ufw ignores rules

Status in ufw package in Ubuntu:
  Incomplete

Bug description:
  With my setting I shouldn't be able to surf web, but I can do it (without 
proxy/vpn)
  This problem happens after `iptables -F` and only way to solve it, is to 
reboot PC. I tried `ufw reload` , too

  ProblemType: Bug
  DistroRelease: Ubuntu 21.04
  Package: ufw 0.36-7.1
  ProcVersionSignature: Ubuntu 5.11.0-25.27-generic 5.11.22
  Uname: Linux 5.11.0-25-generic x86_64
  ApportVersion: 2.20.11-0ubuntu65.1
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: XFCE
  Date: Mon Jul 26 11:53:17 2021
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2021-06-17 (38 days ago)
  InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420)
  PackageArchitecture: all
  SourcePackage: ufw
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.default.ufw: 2021-07-25T22:22:29.221649

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1938005/+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 1938005] Re: ufw ignores rules

2021-08-06 Thread Jamie Strandboge
Thank you for the bug report. You mentioned that the problem happens
after running `iptables -F`. This command removes all the rules from the
firewall (see man iptables) so it would be expected that the firewall
would not work correctly after running this.

I'm going to mark this as Invalid, but if you have more information,
feel free to add it.

** Changed in: ufw (Ubuntu)
   Status: New => Invalid

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

Title:
  ufw ignores rules

Status in ufw package in Ubuntu:
  Invalid

Bug description:
  With my setting I shouldn't be able to surf web, but I can do it (without 
proxy/vpn)
  This problem happens after `iptables -F` and only way to solve it, is to 
reboot PC. I tried `ufw reload` , too

  ProblemType: Bug
  DistroRelease: Ubuntu 21.04
  Package: ufw 0.36-7.1
  ProcVersionSignature: Ubuntu 5.11.0-25.27-generic 5.11.22
  Uname: Linux 5.11.0-25-generic x86_64
  ApportVersion: 2.20.11-0ubuntu65.1
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: XFCE
  Date: Mon Jul 26 11:53:17 2021
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2021-06-17 (38 days ago)
  InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420)
  PackageArchitecture: all
  SourcePackage: ufw
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.default.ufw: 2021-07-25T22:22:29.221649

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1938005/+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 1921350] Re: UFW hangs indefinitely on any action

2021-03-25 Thread Jamie Strandboge
Thanks you for reporting a bug. Are there other ufw commands running at the 
same time? Eg, what is the output of:
$ ps auxww|grep ufw

** Changed in: ufw (Ubuntu)
   Status: New => Incomplete

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

Title:
  UFW hangs indefinitely on any action

Status in ufw package in Ubuntu:
  Incomplete

Bug description:
  When installing a new cloudserver (on Amazon EC2, if it makes a
  difference), UFW completely hangs on any command, for example ufw
  status. Interrupting it with Ctrl+C yields this backtrace:

  Traceback (most recent call last):
File "/usr/sbin/ufw", line 130, in 
  lock = create_lock(lockfile=lockfile, dryrun=pr.dryrun)
File "/usr/lib/python3/dist-packages/ufw/util.py", line 1112, in create_lock
  fcntl.lockf(lock, fcntl.LOCK_EX)
  KeyboardInterrupt

  The line numbers are always the same.

  The platform is Ubuntu Server 20.04 (Ubuntu 20.04.2 LTS), from the
  Amazon image. I have not seen this bug on other servers. UFW is
  version 0.36.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1921350/+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 1914816] Re: ufw not logging if it decides to stop all traffic ? Confused

2021-03-01 Thread Jamie Strandboge
Thanks for the additional information! :)

** Changed in: ufw (Ubuntu)
   Status: Incomplete => Invalid

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

Title:
  ufw not logging if it decides to stop all traffic ?  Confused

Status in ufw package in Ubuntu:
  Invalid

Bug description:
  Sorry, this is going to be a very bad report.  Here's what I did:
  - installed gufw and enabled it, no rules, just default incoming=deny 
outgoing=accept
  - rebooted
  - Ethernet says it connected
  - no network access; ping 1.1.1.1 fails
  - launch gufw, and it says it's disabled (the whole firewall)
  - I think eventually I figured out that iptables had been emptied and INPUT 
chain set to DROP

  After many travails, I captured a piece of dmesg output as the system
  was booting, and I think it shows ufw trying to check IPv6 status and
  deciding to stop everything.  At least logging (which was set to full
  in gufw) suddenly stops.

  In network manager, I've tried to say "ignore IPv6".  I'm not sure if
  this trouble is related to fiddling with the "only work if IPv4 is
  enabled" check-box, which seems to have a ToolTip that is exactly
  backwards.  My ISP does not give IPv6 service.  I've tried many
  settings of the IPv6 drop-down in System Settings / Network GUI,
  setting and clearing the IPv4 and IPv6 required check-boxes, etc.

  So, I'm totally confused, but I think the log shows that logging
  suddenly stops (from full to zero), which must mean ufw detected some
  condition that made it empty out the iptables and set everything to
  DROP ?  If so, ufw should have logged a message saying it was doing
  so, and I don't see such a message.  So, if I'm right, at least this
  is a feature request that ufw should log a message when it decides to
  stop all IPv4 or IPv6 traffic and/or stop logging and/or wipe out all
  rules.

  Sorry about the mess of a report.

  I'm using Kubuntu 20.10, gufw 20.10.0-0ubuntu1, ufw 0.36-7

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: ufw (not installed)
  ProcVersionSignature: Ubuntu 5.8.0-41.46-generic 5.8.18
  Uname: Linux 5.8.0-41-generic x86_64
  ApportVersion: 2.20.11-0ubuntu50.5
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: KDE
  Date: Fri Feb  5 20:35:18 2021
  InstallationDate: Installed on 2021-02-03 (2 days ago)
  InstallationMedia: Kubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022)
  SourcePackage: ufw
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1914816/+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 1914816] Re: ufw not logging if it decides to stop all traffic ? Confused

2021-03-01 Thread Jamie Strandboge
The check is not free, but it is an interesting idea to do this. I've
created a wishlist bug for it:
https://bugs.launchpad.net/ufw/+bug/1917325

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

Title:
  ufw not logging if it decides to stop all traffic ?  Confused

Status in ufw package in Ubuntu:
  Invalid

Bug description:
  Sorry, this is going to be a very bad report.  Here's what I did:
  - installed gufw and enabled it, no rules, just default incoming=deny 
outgoing=accept
  - rebooted
  - Ethernet says it connected
  - no network access; ping 1.1.1.1 fails
  - launch gufw, and it says it's disabled (the whole firewall)
  - I think eventually I figured out that iptables had been emptied and INPUT 
chain set to DROP

  After many travails, I captured a piece of dmesg output as the system
  was booting, and I think it shows ufw trying to check IPv6 status and
  deciding to stop everything.  At least logging (which was set to full
  in gufw) suddenly stops.

  In network manager, I've tried to say "ignore IPv6".  I'm not sure if
  this trouble is related to fiddling with the "only work if IPv4 is
  enabled" check-box, which seems to have a ToolTip that is exactly
  backwards.  My ISP does not give IPv6 service.  I've tried many
  settings of the IPv6 drop-down in System Settings / Network GUI,
  setting and clearing the IPv4 and IPv6 required check-boxes, etc.

  So, I'm totally confused, but I think the log shows that logging
  suddenly stops (from full to zero), which must mean ufw detected some
  condition that made it empty out the iptables and set everything to
  DROP ?  If so, ufw should have logged a message saying it was doing
  so, and I don't see such a message.  So, if I'm right, at least this
  is a feature request that ufw should log a message when it decides to
  stop all IPv4 or IPv6 traffic and/or stop logging and/or wipe out all
  rules.

  Sorry about the mess of a report.

  I'm using Kubuntu 20.10, gufw 20.10.0-0ubuntu1, ufw 0.36-7

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: ufw (not installed)
  ProcVersionSignature: Ubuntu 5.8.0-41.46-generic 5.8.18
  Uname: Linux 5.8.0-41-generic x86_64
  ApportVersion: 2.20.11-0ubuntu50.5
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: KDE
  Date: Fri Feb  5 20:35:18 2021
  InstallationDate: Installed on 2021-02-03 (2 days ago)
  InstallationMedia: Kubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022)
  SourcePackage: ufw
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1914816/+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 881137] Re: UFW does not clean iptables setting from /etc/ufw/before.rules

2021-02-13 Thread Jamie Strandboge
CzBiX, ufw does not yet manage the nat table (though there have been a
couple of false starts). However, it does manage the FORWARD chain with
'ufw route' so it is possible for you to create a chain in the nat table
in /etc/ufw/before.rules, and then use ufw route for other things. This
is described in 'man ufw-framework' in the EXAMPLES section.

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

Title:
  UFW does not clean iptables setting from /etc/ufw/before.rules

Status in ufw package in Ubuntu:
  Won't Fix

Bug description:
  Adding some additional settings to /etc/ufw/before.rules is not
  deleted when ufw is stopped.

  I added these lines at top of file /etc/ufw/before.rules

  *nat
  :POSTROUTING ACCEPT [0:0]
  -A POSTROUTING -o eth0 -j MASQUERADE
  COMMIT

  Then I reloaded ufw firewall with command: ufw reload. Output from
  iptables-save

  $ iptables-save -t nat
  *nat
  :PREROUTING ACCEPT [4:478]
  :INPUT ACCEPT [4:478]
  :OUTPUT ACCEPT [0:0]
  :POSTROUTING ACCEPT [0:0]
  -A POSTROUTING -o eth0 -j MASQUERADE 
  COMMIT

  Then I reloaded ufw firewall again:

  $ iptables-save -t nat
  *nat
  :PREROUTING ACCEPT [4:478]
  :INPUT ACCEPT [4:478]
  :OUTPUT ACCEPT [0:0]
  :POSTROUTING ACCEPT [0:0]
  -A POSTROUTING -o eth0 -j MASQUERADE 
  -A POSTROUTING -o eth0 -j MASQUERADE 
  COMMIT

  And ufw reload again

  $ iptables-save -t nat
  *nat
  :PREROUTING ACCEPT [4:478]
  :INPUT ACCEPT [4:478]
  :OUTPUT ACCEPT [0:0]
  :POSTROUTING ACCEPT [0:0]
  -A POSTROUTING -o eth0 -j MASQUERADE 
  -A POSTROUTING -o eth0 -j MASQUERADE 
  -A POSTROUTING -o eth0 -j MASQUERADE
  COMMIT

  And again and postrouting is never deleted when ufw is stopped and
  added again when stared. Same happen if I stop ufw firewall with: $
  stop ufw. nat lines are not cleaned.

  UFW should remove all iptables settings specified in config files
  after ufw is stopped! This can be dangerous if apt-get is updating
  some ufw files and scripts needs to reload ufw (some lines will be
  more times).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/881137/+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 1914816] Re: ufw not logging if it decides to stop all traffic ? Confused

2021-02-13 Thread Jamie Strandboge
Hi. A few things: ufw is capable of logging (see 'man ufw' the part
about 'ufw logging' as well as per rule logging with 'ufw ... log' or
'ufw ... log-all'. It is also capable of ipv6 (see /etc/default/ufw.
Also, gufw is a different project than ufw, but it sounds like the issue
you saw may be seeing is another firewall is in place.

What is the output of 'sudo /usr/share/ufw/check-requirements'?

** Changed in: ufw (Ubuntu)
   Status: New => Incomplete

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

Title:
  ufw not logging if it decides to stop all traffic ?  Confused

Status in ufw package in Ubuntu:
  Incomplete

Bug description:
  Sorry, this is going to be a very bad report.  Here's what I did:
  - installed gufw and enabled it, no rules, just default incoming=deny 
outgoing=accept
  - rebooted
  - Ethernet says it connected
  - no network access; ping 1.1.1.1 fails
  - launch gufw, and it says it's disabled (the whole firewall)
  - I think eventually I figured out that iptables had been emptied and INPUT 
chain set to DROP

  After many travails, I captured a piece of dmesg output as the system
  was booting, and I think it shows ufw trying to check IPv6 status and
  deciding to stop everything.  At least logging (which was set to full
  in gufw) suddenly stops.

  In network manager, I've tried to say "ignore IPv6".  I'm not sure if
  this trouble is related to fiddling with the "only work if IPv4 is
  enabled" check-box, which seems to have a ToolTip that is exactly
  backwards.  My ISP does not give IPv6 service.  I've tried many
  settings of the IPv6 drop-down in System Settings / Network GUI,
  setting and clearing the IPv4 and IPv6 required check-boxes, etc.

  So, I'm totally confused, but I think the log shows that logging
  suddenly stops (from full to zero), which must mean ufw detected some
  condition that made it empty out the iptables and set everything to
  DROP ?  If so, ufw should have logged a message saying it was doing
  so, and I don't see such a message.  So, if I'm right, at least this
  is a feature request that ufw should log a message when it decides to
  stop all IPv4 or IPv6 traffic and/or stop logging and/or wipe out all
  rules.

  Sorry about the mess of a report.

  I'm using Kubuntu 20.10, gufw 20.10.0-0ubuntu1, ufw 0.36-7

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: ufw (not installed)
  ProcVersionSignature: Ubuntu 5.8.0-41.46-generic 5.8.18
  Uname: Linux 5.8.0-41-generic x86_64
  ApportVersion: 2.20.11-0ubuntu50.5
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: KDE
  Date: Fri Feb  5 20:35:18 2021
  InstallationDate: Installed on 2021-02-03 (2 days ago)
  InstallationMedia: Kubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022)
  SourcePackage: ufw
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1914816/+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 1897369] Re: apparmor: Allow cups-browsed to change nice value (CAP_SYS_NICE)

2020-12-01 Thread Jamie Strandboge
Till, it allows quite a few things (from man capabilities):

CAP_SYS_NICE
   * Raise  process nice value (nice(2), setpriority(2)) and change the
 nice value for arbitrary processes;
   * set real-time scheduling policies for  calling  process,  and  set
 scheduling   policies   and  priorities  for  arbitrary  processes
 (sched_setscheduler(2), sched_setparam(2), sched_setattr(2));
   * set CPU affinity for arbitrary processes (sched_setaffinity(2));
   * set I/O scheduling class and priority for arbitrary processes (io‐
 prio_set(2));
   * apply  migrate_pages(2) to arbitrary processes and allow processes
 to be migrated to arbitrary nodes;
   * apply move_pages(2) to arbitrary processes;
   * use the MPOL_MF_MOVE_ALL flag with mbind(2) and move_pages(2).

cups-browsed is probably just trying to renice itself, which isn't
terrible for it to try, but it probably fails gracefully with this just
being noise. If it does fail gracefully, you could consider an explicit
deny rule to silence the log. Eg:

  deny capability sys_nice,

That said, we've normally allowed system policy (ie, those shipped in
debs) to use sys_nice if they have a legitimate use case for it.

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

Title:
  apparmor: Allow cups-browsed to change nice value (CAP_SYS_NICE)

Status in cups package in Ubuntu:
  Confirmed

Bug description:
  In Ubuntu 20.04.1 with *cups-browsed* 1.27.4-1, apparmor prevents
  `/usr/sbin/cups-browsed` to change its nice value.

  $ sudo dmesg | grep apparmor
  [541870.509461] audit: type=1400 audit(1600898428.089:60): 
apparmor="DENIED" operation="capable" profile="/usr/sbin/cups-browsed" 
pid=62030 comm="cups-browsed" capability=23  capname="sys_nice"
  [628298.779668] audit: type=1400 audit(1600984854.115:61): 
apparmor="DENIED" operation="capable" profile="/usr/sbin/cups-browsed" 
pid=66850 comm="cups-browsed" capability=23  capname="sys_nice"
  [714667.424963] audit: type=1400 audit(1601071220.527:62): 
apparmor="DENIED" operation="capable" profile="/usr/sbin/cups-browsed" 
pid=76828 comm="cups-browsed" capability=23  capname="sys_nice"

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1897369/+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 1904192] Re: ebtables can not rename just created chain

2020-11-18 Thread Jamie Strandboge
FYI, sponsored Alex's upload to hirsute-proposed where it is building.
Did the same for groovy-proposed and it is sitting in unapproved waiting
for the next steps of the SRU process.

** Changed in: iptables (Ubuntu)
   Status: Confirmed => Fix Committed

** Changed in: iptables (Ubuntu)
 Assignee: (unassigned) => Alex Murray (alexmurray)

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

Title:
  ebtables can not rename just created chain

Status in iptables:
  Unknown
Status in iptables package in Ubuntu:
  Fix Committed
Status in iptables source package in Groovy:
  In Progress
Status in iptables package in Debian:
  Unknown
Status in iptables package in Fedora:
  Fix Committed

Bug description:
  [SRU]

   * Changes that went into 1.8.5 ave broken the errno handling.
 In particular loading extensions. Due to that it has become
 impossible to rename rules.

   * Upstream has created a fix and this backports that change to
 Ubuntu
 => 
http://git.netfilter.org/iptables/commit/?id=55b7c71dce7144f4dc0297c17abf0f04879ee247

  [Test Case]

   * # ebtables -t nat -N foo
 # ebtables -t nat -E foo bar
 ebtables v1.8.5 (nf_tables): Chain 'foo' doesn't exists

   * with the fix the above command sequence works

  [Where problems could occur]

   * The change moved code from nft_chain_user_rename to do_commandeb and 
 therefore in theory any ebtables/xtables subcommand could be affected.
 Yet what it does is just resetting the error code in a better place, so 
 while it "could" affect every subcommand it should (tm) not do so.
 

  [Other Info]
   
   * n/a

  
  ---

  Hi,
  I have an issue with ebtables that affects libvirt.
  While initially found in hirsute I had to realize this is broken in
  Groovy and even Bionic (might be a different reason back then) as well right 
now.
  But working in Focal (witch matches my memory of it being good before [1]).

  I was isolating the commands that libvirt runs (identical between Focal
  and Hirsute) to find a simplified trigger. Gladly I found one that leaves
  libvirt and other components out of the equation.
  The following works on focal, but fails on the other releases.

  Note: I checked which tool is in use and in both cases it is 
xtables-nft-multi.
  /usr/sbin/ebtables -> /etc/alternatives/ebtables*
  /etc/alternatives/ebtables -> /usr/sbin/ebtables-nft*
  /usr/sbin/ebtables-nft -> xtables-nft-multi*
  So I converted the libvirt issued commands into xtables-nft-multi just to be
  sure in case a system to compare has other alternatives set.

  Focal (Good):
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 
testrule3-renamed
  

  Groovy/Hirsute (Fail):
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 
testrule3-renamed
  ebtables v1.8.5 (nf_tables): Chain 'testrule3' doesn't exists
  Try `ebtables -h' or 'ebtables --help' for more information.

  What might be the root cause for this?

  -- Old test instructions --

  As I said I was tracking a fail in libvirt so the test instructions initially
  were around that:

  # the following us done as 2nd level guest (to not mess with the host,
  # but works on bare metal jst as much)
  uvt-kvm create --host-passthrough --memory 2048 --cpu 4 --disk 16 
--password=ubuntu hirsute-kvm release=hirsute arch=amd64 label=daily
  # On guest then

  sudo apt update
  sudo apt install uvtool uvtool-libvirt
  uvt-simplestreams-libvirt --verbose sync --source 
http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=hirsute
  uvt-kvm create --disk 5 --machine-type ubuntu --password=ubuntu 
hirsute-2nd-lvm release=hirsute arch=amd64 label=daily
  uvt-kvm wait hirsute-2nd-lvm
  virsh shutdown hirsute-2nd-lvm
  virsh edit hirsute-2nd-lvm
  # add this to the network
    
  
    
  virsh start hirsute-2nd-lvm
    error: Failed to start domain hirsute-2nd-nwfilter
    error: internal error: applyDHCPOnlyRules failed - spoofing not protected!

  FYI: Get helpful log details with these in /etc/libvirt/libvirtd.conf
  log_filters="1:util.firewall"
  log_outputs="1:syslog:libvirtd"

  -- --

  [1]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1758037

To manage notifications about this bug go to:
https://bugs.launchpad.net/iptables/+bug/1904192/+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 1898547] Re: neutron-linuxbridge-agent fails to start with iptables 1.8.5

2020-11-04 Thread Jamie Strandboge
FYI, 1.8.5-3ubuntu3 was uploaded to hirsute-proposed yesterday.
1.8.5-3ubuntu2.20.10.1 is in the unapproved queue for groovy-proposed.
Alex said he'd do the SRU paperwork.

** Changed in: iptables (Ubuntu Hirsute)
   Status: Triaged => Fix Committed

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

Title:
  neutron-linuxbridge-agent fails to start with iptables 1.8.5

Status in iptables package in Ubuntu:
  Fix Committed
Status in neutron package in Ubuntu:
  Invalid
Status in iptables source package in Groovy:
  Triaged
Status in neutron source package in Groovy:
  Invalid
Status in iptables source package in Hirsute:
  Fix Committed
Status in neutron source package in Hirsute:
  Invalid

Bug description:
  Ubuntu Groovy (20.10)
  kernel 5.8.0-20-generic
  neutron-linuxbridge-agent: 2:17.0.0~git2020091014.215a541bd4-0ubuntu1
  iptables: 1.8.5-3ubuntu1 (nf_tables)
  iptables-restore points to xtables-nft-multi

  After upgrading iptables from 1.8.4 to 1.8.5 and rebooting the neutron 
network node, neutron-linuxbridge-agent didn't properly start anymore.
  The log file shows many errors like:

  2020-10-05 10:20:37.998 551 ERROR
  neutron.plugins.ml2.drivers.agent._common_agent ; Stdout: ; Stderr:
  iptables-restore: line 29 failed

  Downgrading iptables to 1.8.4 solves the problem.

  Trying to do what the linuxbridge agent does:
  2020-10-05 10:20:37.998 551 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent *filter
  2020-10-05 10:20:37.998 551 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent :FORWARD - [0:0]

  shows that

  iptables-restore 

[Touch-packages] [Bug 1899218] Re: Incorrect warning from apparmor_parser on force complained profiles

2020-10-12 Thread Jamie Strandboge
FYI, this is part of the groovy upload in unapproved.

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

** Changed in: apparmor (Ubuntu)
 Assignee: (unassigned) => John Johansen (jjohansen)

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

Title:
  Incorrect warning from apparmor_parser on force complained profiles

Status in apparmor package in Ubuntu:
  Fix Committed

Bug description:
  apparmor_parser on a force complained profile produces an incorrect
  warning message:

  $ sudo apparmor_parser -rW /etc/apparmor.d/usr.sbin.sssd
  Warning: found usr.sbin.sssd in /etc/apparmor.d/force-complain, forcing 
complain mode
  Warning from /etc/apparmor.d/usr.sbin.sssd (/etc/apparmor.d/usr.sbin.sssd 
line 54): Warning failed to create cache: usr.sbin.sssd

  Even though not generating the cache at all is expected, the warning
  should describe caching is disabled for force complained profiles
  instead of failure to create it.

  $ lsb_release -rd
  Description:  Ubuntu Groovy Gorilla (development branch)
  Release:  20.10

  $ apt-cache policy apparmor
  apparmor:
    Installed: 3.0.0~beta1-0ubuntu6
    Candidate: 3.0.0~beta1-0ubuntu6
    Version table:
   *** 3.0.0~beta1-0ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1899218/+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 1899046] Re: /usr/bin/aa-notify:ModuleNotFoundError:/usr/bin/aa-notify@39

2020-10-12 Thread Jamie Strandboge
This has been uploaded to groovy and is currently in unapproved.

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

** Changed in: apparmor (Ubuntu)
 Assignee: (unassigned) => Emilia Torino (emitorino)

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

Title:
  /usr/bin/aa-notify:ModuleNotFoundError:/usr/bin/aa-notify@39

Status in apparmor package in Ubuntu:
  Fix Committed

Bug description:
  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
apparmor.  This problem was most recently seen with package version 
3.0.0~beta1-0ubuntu6, the problem page at 
https://errors.ubuntu.com/problem/69bb6832fe7b294bd7e2d75970fdc903f412c409 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.
  If you do not have access to the Ubuntu Error Tracker and are a software 
developer, you can request it at http://forms.canonical.com/reports/.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1899046/+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 1726856] Re: ufw does not start automatically at boot

2020-10-05 Thread Jamie Strandboge
@Muhammad - can you run:

$ sudo /usr/share/ufw/check-requirements

and paste the results?

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

Title:
  ufw does not start automatically at boot

Status in ufw:
  Invalid
Status in ufw package in Ubuntu:
  Invalid
Status in ufw source package in Xenial:
  Invalid
Status in ufw source package in Bionic:
  Invalid
Status in ufw source package in Cosmic:
  Invalid
Status in ufw source package in Disco:
  Invalid

Bug description:
  Whenever I boot into 17.10 ufw is always inactive, even though
  /etc/ufw/ufw.conf has this:

  # Set to yes to start on boot. If setting this remotely, be sure to add a rule
  # to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp'
  ENABLED=yes

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: ufw 0.35-5
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 24 13:56:40 2017
  InstallationDate: Installed on 2015-04-01 (936 days ago)
  InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 
(20140722.2)
  PackageArchitecture: all
  SourcePackage: ufw
  UpgradeStatus: Upgraded to artful on 2017-10-24 (0 days ago)
  mtime.conffile..etc.default.ufw: 2015-06-17T22:01:02.089170

To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/1726856/+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 1894195] Re: FFe: Merge iptables 1.8.5-3 (main) from Debian sid (main)

2020-09-25 Thread Jamie Strandboge
** Changed in: iptables (Ubuntu)
   Status: New => Fix Committed

** Changed in: iptables (Ubuntu)
 Assignee: (unassigned) => Alex Murray (alexmurray)

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

Title:
  FFe: Merge iptables 1.8.5-3 (main) from Debian sid (main)

Status in iptables package in Ubuntu:
  Fix Committed

Bug description:
  Please merge iptables 1.8.5-3 (main) from Debian sid (main)

  Explanation of FeatureFreeze exception:
  Current iptables is using the same upstream version in focal, which had 
problems with the nft backend and was then reverted to the legacy backend.
  1.8.5 has many fixes for the nft backend. For example these Debian bugs are 
fixed in 1.8.5:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950535
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961117
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968457
  Please merge it.

  Changelog entries since current groovy version 1.8.4-3ubuntu3:

  iptables (1.8.5-3) unstable; urgency=medium

    * [2d587e5] src:iptables: bump build-dep version on libnftnl to
  1.1.6

   -- Arturo Borrero Gonzalez   Tue, 25 Aug 2020
  11:56:55 +0200

  iptables (1.8.5-2) unstable; urgency=medium

    [ Alberto Molina Coballes ]
    * [d90516d] d/control: modify breaks and replaces fields (Closes: #949576)
    * [4754a45] d/not-installed: arch independ files
    * [780330f] d/tests/control: Run iptables-legacy-* tests explicitly

    [ Arturo Borrero Gonzalez ]
    * [6fb6557] d/patches: add -upstream-fix-xtables-translate.patch
  (Closes: #962724)

   -- Arturo Borrero Gonzalez   Wed, 24 Jun 2020
  10:56:19 +0200

  iptables (1.8.5-1) unstable; urgency=medium

    [ Debian Janitor ]
    * [c3deeb3] Wrap long lines in changelog entries: 1.8.2-1, 1.8.0-1~exp1,
    1.6.0-1.
    * [214468e] Update standards version to 4.5.0, no changes needed.

    [ Arturo Borrero Gonzalez ]
    * [eb1d7c5] New upstream version 1.8.5 (Closes: #950535)
    * [7a119db] d/patches: drop all patches
    * [ec63c87] libxtables12.symbols: add new symbol
    * [4056ce6] iptables: bump debhelper-compat to 13

   -- Arturo Borrero Gonzalez   Thu, 04 Jun 2020
  13:33:22 +0200

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1894195/+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 1887577] Re: DEP8: Invalid capability setuid

2020-09-23 Thread Jamie Strandboge
Removed the update_excuse and update_excuses tags based on Steve and
Alex's comments.

** Tags removed: update-excuse update-excuses

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

Title:
  DEP8: Invalid capability setuid

Status in apparmor package in Ubuntu:
  Fix Committed

Bug description:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-
  groovy/groovy/amd64/a/apparmor/20200713_202347_dd214@/log.gz

  Excuses is showing apparmor failing dep8 tests when they are triggered
  by another package.

  last time apparmor was uploaded was on May 14th, and this is the
  package under test:

  https://launchpad.net/ubuntu/+source/apparmor/2.13.3-7ubuntu6

  
  The errors are like this:
  FAIL: test_profile_newer_rewrites_cache (__main__.AAParserAltCacheTests)
  --
  Traceback (most recent call last):
File "/tmp/tmp.40nJ4LqRYT/parser/tst/testlib.py", line 50, in 
new_unittest_func
  return unittest_func(self)
File "./caching.py", line 448, in test_profile_newer_rewrites_cache
  self._generate_cache_file()
File "./caching.py", line 257, in _generate_cache_file
  self.run_cmd_check(cmd)
File "/tmp/tmp.40nJ4LqRYT/parser/tst/testlib.py", line 73, in run_cmd_check
  self.assertEqual(rc, expected_rc, "Got return code %d, expected 
%d\nCommand run: %s\nOutput: %s" % (rc, expected_rc, (' '.join(command)), 
report))
  AssertionError: 1 != 0 : Got return code 1, expected 0
  Command run: ../apparmor_parser --config-file=./parser.conf --base 
/tmp/aa-caching-s3l9wndt --skip-kernel-load --cache-loc 
/tmp/aa-caching-s3l9wndt/cache --cache-loc 
/tmp/aa-caching-s3l9wndt/aa-alt-cachezi43qt78 -q --write-cache -r 
/tmp/aa-caching-s3l9wndt/sbin.pingy
  Output: AppArmor parser error for /tmp/aa-caching-s3l9wndt/sbin.pingy in 
/tmp/aa-caching-s3l9wndt/suid-abstraction at line 3: Invalid capability setuid.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1887577/+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 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore

2020-09-23 Thread Jamie Strandboge
FYI, I removed the block-proposed tag since ubuntu6 fixes this bug.

** Tags removed: block-proposed

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

Title:
  Apparmor 3.0.0 does not load profiles in containers anymore

Status in apparmor package in Ubuntu:
  Fix Committed

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore

2020-09-22 Thread Jamie Strandboge
I uploaded 3.0.0~beta1-0ubuntu6 just now that should address this issue.
Thanks Christian for your debugging!

** Changed in: apparmor (Ubuntu)
   Status: In Progress => 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/1895967

Title:
  Apparmor 3.0.0 does not load profiles in containers anymore

Status in apparmor package in Ubuntu:
  Fix Committed

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1871148] Re: services start before apparmor profiles are loaded

2020-09-22 Thread Jamie Strandboge
This was fixed in snapd in 2.44 via
https://github.com/snapcore/snapd/pull/8467

** Changed in: snapd (Ubuntu)
   Status: In Progress => Fix Released

** Changed in: snapd (Ubuntu Focal)
   Status: In Progress => Fix Released

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

Title:
  services start before apparmor profiles are loaded

Status in AppArmor:
  Invalid
Status in snapd:
  Fix Released
Status in apparmor package in Ubuntu:
  Fix Released
Status in snapd package in Ubuntu:
  Fix Released
Status in zsys package in Ubuntu:
  Invalid
Status in apparmor source package in Focal:
  Fix Released
Status in snapd source package in Focal:
  Fix Released
Status in zsys source package in Focal:
  Invalid

Bug description:
  Per discussion with Zyga in #snapd on Freenode, I have hit a race
  condition where services are being started by the system before
  apparmor has been started. I have a complete log of my system showing
  the effect somewhere within at https://paste.ubuntu.com/p/Jyx6gfFc3q/.
  Restarting apparmor using `sudo systemctl restart apparmor` is enough
  to bring installed snaps back to full functionality.

  Previously, when running any snap I would receive the following in the
  terminal:

  ---
  cannot change profile for the next exec call: No such file or directory
  snap-update-ns failed with code 1: File exists
  ---

  Updated to add for Jamie:

  $ snap version
  snap2.44.2+20.04
  snapd   2.44.2+20.04
  series  16
  ubuntu  20.04
  kernel  5.4.0-21-generic

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1871148/+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 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore

2020-09-22 Thread Jamie Strandboge
** Changed in: apparmor (Ubuntu)
   Status: Confirmed => In Progress

** Changed in: apparmor (Ubuntu)
 Assignee: (unassigned) => Jamie Strandboge (jdstrand)

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

Title:
  Apparmor 3.0.0 does not load profiles in containers anymore

Status in apparmor package in Ubuntu:
  In Progress

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895060] Re: [FFe] apparmor 3 upstream release

2020-09-22 Thread Jamie Strandboge
FYI, there was a components mismatch where apparmor-notify pulled
python3-notify2 (and its Depends) into main. For now, I've demoted
apparmor-notify to universe and adjusted the seed (in practical terms,
the security team will fix bugs in apparmor-notify regardless of where
it lives). We might revisit promoting apparmor-notify at a future date.

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

Title:
  [FFe] apparmor 3 upstream release

Status in apparmor package in Ubuntu:
  Fix Committed

Bug description:
  As per the draft upstream release notes[1]:

  AppArmor 3.0 is a major new release of the AppArmor user space that makes
  an important change to policy development and support. Its focus is
  transitioning policy to the new features ABI and as such other new features
  have been limited.

  Apprmor 3.0 is a bridge release between older AppArmor 2.x policy and the
  newer AppArmor 3 style policy which requires the declaration of a features
  abi. As such AppArmor 3.0 will be a short lived release, and will not
  receive long term support. The following AppArmor 3.1 feature release is
  planned to be a regular release, please take this into account when
  including AppArmor 3.0 into a distro release.

  As such, Ubuntu 20.10 provides a great opportunity to introduce AppArmor3
  to Ubuntu and provide these new capabilities to users and system
  administrators. The short support lifespan of Ubuntu 20.10 ensures that
  there is alignment with the limited support lifetime of AppArmor 3.0 from
  upstream, whilst giving good exposure and opportunity to test and exercise
  the new features in AppArmor 3.x on the road to Ubuntu 22.04. A highlight
  of new features provided by AppArmor 3.0 include:

  - Policy now must declare the feature abi it was developed for if it is to
    use any new features. This ensures that old policy will not become
    incompatible with new kernels that support additional AppArmor features.
  - The use of profile names that are based on pathnames are deprecated.
  - Support for new kernel features (requires appropriate features abi
    tagging in policy)
    - upstream v8 network socket rules
    - xattr attachment conditionals
    - capabilities PERFMON and BPF
  - Improved compiler warnings and semantic checks
  - aa-status rewritten in C (previously was python) with additional features
    - supports use in systems/images where python is not available
    - supports kill, unconfined and mixed profile modes
  - Rewritten aa-notify (previously was perl, now python3)
    - shared backend with other python tools
    - support use of aa.CONFDIR instead of hard coded /etc/apparmor
    - improved message layout
  - Improved support for kernels that support LSM stacking
  - New utility aa-features-abi to extract and work with kernel abi features
  - New utility aa-load to load binary policy without calling the
    apparmor_parser
  - Support for profile modes
    - enforce (default when no mode flag is supplied)
    - kill (experimental)
    - unconfined (experimental)

  The use of the new AppArmor profile feature ABI includes a default
  configuration (for the Ubuntu packaged version of AppArmor proposed in this
  FFE) for the AppArmor features within the 5.4 Linux kernel - this ensures
  that all profiles provided in AppArmor3 for groovy will conform to this
  feature set and that upgrades to the kernel version (say to 5.8) that may
  include newer AppArmor confinement features will not result in additional
  policy denials as a result (since say the existing profile did not specify
  a rule for a new AppArmor feature which is now supported by the upgraded
  kernel). This ensures that there will be no regressions in application
  behaviour as a result of AppArmor kernel feature upgrades.

  TESTING

  This has been extensively tested by the security team - this includes
  following the documented Ubuntu merges test plan[2] for AppArmor and the
  extensive QA Regression Tests[3] for AppArmor as well. This ensures that the
  various applications that make heavy use of AppArmor (LXD, docker, lxc,
  dbus, libvirt, snapd etc) have all been exercised and no regressions have
  been observed. All tests have passed and demonstrated both apparmor and the
  various applications that use it to be working as expected.

  BUILD LOGS

  This is currently uploaded to groovy-proposed, build logs can be found on
  Launchpad at:
  https://launchpad.net/ubuntu/+source/apparmor/3.0.0~beta1-0ubuntu1

  INSTALL LOG

  See attached
  
(https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+attachment/5411197/+files
  /groovy-proposed-apparmor-install.log) for a log showing install of
  the packages from groovy-proposed

  [1] https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_3.0
  [2] https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor
  [3] 

[Touch-packages] [Bug 1895060] Re: [FFe] apparmor 3 upstream release

2020-09-21 Thread Jamie Strandboge
Thanks! Uploaded:
https://launchpad.net/ubuntu/+source/apparmor/3.0.0~beta1-0ubuntu5

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

** Changed in: apparmor (Ubuntu)
 Assignee: (unassigned) => Alex Murray (alexmurray)

** Changed in: apparmor (Ubuntu)
Milestone: None => ubuntu-20.10

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

Title:
  [FFe] apparmor 3 upstream release

Status in apparmor package in Ubuntu:
  Fix Committed

Bug description:
  As per the draft upstream release notes[1]:

  AppArmor 3.0 is a major new release of the AppArmor user space that makes
  an important change to policy development and support. Its focus is
  transitioning policy to the new features ABI and as such other new features
  have been limited.

  Apprmor 3.0 is a bridge release between older AppArmor 2.x policy and the
  newer AppArmor 3 style policy which requires the declaration of a features
  abi. As such AppArmor 3.0 will be a short lived release, and will not
  receive long term support. The following AppArmor 3.1 feature release is
  planned to be a regular release, please take this into account when
  including AppArmor 3.0 into a distro release.

  As such, Ubuntu 20.10 provides a great opportunity to introduce AppArmor3
  to Ubuntu and provide these new capabilities to users and system
  administrators. The short support lifespan of Ubuntu 20.10 ensures that
  there is alignment with the limited support lifetime of AppArmor 3.0 from
  upstream, whilst giving good exposure and opportunity to test and exercise
  the new features in AppArmor 3.x on the road to Ubuntu 22.04. A highlight
  of new features provided by AppArmor 3.0 include:

  - Policy now must declare the feature abi it was developed for if it is to
    use any new features. This ensures that old policy will not become
    incompatible with new kernels that support additional AppArmor features.
  - The use of profile names that are based on pathnames are deprecated.
  - Support for new kernel features (requires appropriate features abi
    tagging in policy)
    - upstream v8 network socket rules
    - xattr attachment conditionals
    - capabilities PERFMON and BPF
  - Improved compiler warnings and semantic checks
  - aa-status rewritten in C (previously was python) with additional features
    - supports use in systems/images where python is not available
    - supports kill, unconfined and mixed profile modes
  - Rewritten aa-notify (previously was perl, now python3)
    - shared backend with other python tools
    - support use of aa.CONFDIR instead of hard coded /etc/apparmor
    - improved message layout
  - Improved support for kernels that support LSM stacking
  - New utility aa-features-abi to extract and work with kernel abi features
  - New utility aa-load to load binary policy without calling the
    apparmor_parser
  - Support for profile modes
    - enforce (default when no mode flag is supplied)
    - kill (experimental)
    - unconfined (experimental)

  The use of the new AppArmor profile feature ABI includes a default
  configuration (for the Ubuntu packaged version of AppArmor proposed in this
  FFE) for the AppArmor features within the 5.4 Linux kernel - this ensures
  that all profiles provided in AppArmor3 for groovy will conform to this
  feature set and that upgrades to the kernel version (say to 5.8) that may
  include newer AppArmor confinement features will not result in additional
  policy denials as a result (since say the existing profile did not specify
  a rule for a new AppArmor feature which is now supported by the upgraded
  kernel). This ensures that there will be no regressions in application
  behaviour as a result of AppArmor kernel feature upgrades.

  TESTING

  This has been extensively tested by the security team - this includes
  following the documented Ubuntu merges test plan[2] for AppArmor and the
  extensive QA Regression Tests[3] for AppArmor as well. This ensures that the
  various applications that make heavy use of AppArmor (LXD, docker, lxc,
  dbus, libvirt, snapd etc) have all been exercised and no regressions have
  been observed. All tests have passed and demonstrated both apparmor and the
  various applications that use it to be working as expected.

  BUILD LOGS

  This is currently uploaded to groovy-proposed, build logs can be found on
  Launchpad at:
  https://launchpad.net/ubuntu/+source/apparmor/3.0.0~beta1-0ubuntu1

  INSTALL LOG

  See attached
  
(https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+attachment/5411197/+files
  /groovy-proposed-apparmor-install.log) for a log showing install of
  the packages from groovy-proposed

  [1] https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_3.0
  [2] https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor
  [3] 

[Touch-packages] [Bug 1895060] Re: [FFe] apparmor 3 upstream release

2020-09-18 Thread Jamie Strandboge
FYI, I accidentally violated the FFe process and uploaded (with a
subsequent binary copy) to groovy-proposed. None of that migrated, so I
deleted what was in groovy-proposed and am now attaching the debdiff,
which has patches to pass proposed migration (we believe). Sorry for the
snafu.

** Patch added: "apparmor_2.13.3-7ubuntu6_to_3.0.0~beta1-0ubuntu5.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+attachment/5412212/+files/apparmor_2.13.3-7ubuntu6_to_3.0.0~beta1-0ubuntu5.debdiff

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

Title:
  [FFe] apparmor 3 upstream release

Status in apparmor package in Ubuntu:
  New

Bug description:
  As per the draft upstream release notes[1]:

  AppArmor 3.0 is a major new release of the AppArmor user space that makes
  an important change to policy development and support. Its focus is
  transitioning policy to the new features ABI and as such other new features
  have been limited.

  Apprmor 3.0 is a bridge release between older AppArmor 2.x policy and the
  newer AppArmor 3 style policy which requires the declaration of a features
  abi. As such AppArmor 3.0 will be a short lived release, and will not
  receive long term support. The following AppArmor 3.1 feature release is
  planned to be a regular release, please take this into account when
  including AppArmor 3.0 into a distro release.

  As such, Ubuntu 20.10 provides a great opportunity to introduce AppArmor3
  to Ubuntu and provide these new capabilities to users and system
  administrators. The short support lifespan of Ubuntu 20.10 ensures that
  there is alignment with the limited support lifetime of AppArmor 3.0 from
  upstream, whilst giving good exposure and opportunity to test and exercise
  the new features in AppArmor 3.x on the road to Ubuntu 22.04. A highlight
  of new features provided by AppArmor 3.0 include:

  - Policy now must declare the feature abi it was developed for if it is to
    use any new features. This ensures that old policy will not become
    incompatible with new kernels that support additional AppArmor features.
  - The use of profile names that are based on pathnames are deprecated.
  - Support for new kernel features (requires appropriate features abi
    tagging in policy)
    - upstream v8 network socket rules
    - xattr attachment conditionals
    - capabilities PERFMON and BPF
  - Improved compiler warnings and semantic checks
  - aa-status rewritten in C (previously was python) with additional features
    - supports use in systems/images where python is not available
    - supports kill, unconfined and mixed profile modes
  - Rewritten aa-notify (previously was perl, now python3)
    - shared backend with other python tools
    - support use of aa.CONFDIR instead of hard coded /etc/apparmor
    - improved message layout
  - Improved support for kernels that support LSM stacking
  - New utility aa-features-abi to extract and work with kernel abi features
  - New utility aa-load to load binary policy without calling the
    apparmor_parser
  - Support for profile modes
    - enforce (default when no mode flag is supplied)
    - kill (experimental)
    - unconfined (experimental)

  The use of the new AppArmor profile feature ABI includes a default
  configuration (for the Ubuntu packaged version of AppArmor proposed in this
  FFE) for the AppArmor features within the 5.4 Linux kernel - this ensures
  that all profiles provided in AppArmor3 for groovy will conform to this
  feature set and that upgrades to the kernel version (say to 5.8) that may
  include newer AppArmor confinement features will not result in additional
  policy denials as a result (since say the existing profile did not specify
  a rule for a new AppArmor feature which is now supported by the upgraded
  kernel). This ensures that there will be no regressions in application
  behaviour as a result of AppArmor kernel feature upgrades.

  TESTING

  This has been extensively tested by the security team - this includes
  following the documented Ubuntu merges test plan[2] for AppArmor and the
  extensive QA Regression Tests[3] for AppArmor as well. This ensures that the
  various applications that make heavy use of AppArmor (LXD, docker, lxc,
  dbus, libvirt, snapd etc) have all been exercised and no regressions have
  been observed. All tests have passed and demonstrated both apparmor and the
  various applications that use it to be working as expected.

  BUILD LOGS

  This is currently uploaded to groovy-proposed, build logs can be found on
  Launchpad at:
  https://launchpad.net/ubuntu/+source/apparmor/3.0.0~beta1-0ubuntu1

  INSTALL LOG

  See attached
  
(https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+attachment/5411197/+files
  /groovy-proposed-apparmor-install.log) for a log showing install of
  the packages from 

[Touch-packages] [Bug 1895060] Re: [FFe] apparmor 3 upstream release

2020-09-18 Thread Jamie Strandboge
FYI, 3.0.0~beta1-0ubuntu3 should address the dbus autopkgtest issue.

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

Title:
  [FFe] apparmor 3 upstream release

Status in apparmor package in Ubuntu:
  New

Bug description:
  As per the draft upstream release notes[1]:

  AppArmor 3.0 is a major new release of the AppArmor user space that makes
  an important change to policy development and support. Its focus is
  transitioning policy to the new features ABI and as such other new features
  have been limited.

  Apprmor 3.0 is a bridge release between older AppArmor 2.x policy and the
  newer AppArmor 3 style policy which requires the declaration of a features
  abi. As such AppArmor 3.0 will be a short lived release, and will not
  receive long term support. The following AppArmor 3.1 feature release is
  planned to be a regular release, please take this into account when
  including AppArmor 3.0 into a distro release.

  As such, Ubuntu 20.10 provides a great opportunity to introduce AppArmor3
  to Ubuntu and provide these new capabilities to users and system
  administrators. The short support lifespan of Ubuntu 20.10 ensures that
  there is alignment with the limited support lifetime of AppArmor 3.0 from
  upstream, whilst giving good exposure and opportunity to test and exercise
  the new features in AppArmor 3.x on the road to Ubuntu 22.04. A highlight
  of new features provided by AppArmor 3.0 include:

  - Policy now must declare the feature abi it was developed for if it is to
    use any new features. This ensures that old policy will not become
    incompatible with new kernels that support additional AppArmor features.
  - The use of profile names that are based on pathnames are deprecated.
  - Support for new kernel features (requires appropriate features abi
    tagging in policy)
    - upstream v8 network socket rules
    - xattr attachment conditionals
    - capabilities PERFMON and BPF
  - Improved compiler warnings and semantic checks
  - aa-status rewritten in C (previously was python) with additional features
    - supports use in systems/images where python is not available
    - supports kill, unconfined and mixed profile modes
  - Rewritten aa-notify (previously was perl, now python3)
    - shared backend with other python tools
    - support use of aa.CONFDIR instead of hard coded /etc/apparmor
    - improved message layout
  - Improved support for kernels that support LSM stacking
  - New utility aa-features-abi to extract and work with kernel abi features
  - New utility aa-load to load binary policy without calling the
    apparmor_parser
  - Support for profile modes
    - enforce (default when no mode flag is supplied)
    - kill (experimental)
    - unconfined (experimental)

  The use of the new AppArmor profile feature ABI includes a default
  configuration (for the Ubuntu packaged version of AppArmor proposed in this
  FFE) for the AppArmor features within the 5.4 Linux kernel - this ensures
  that all profiles provided in AppArmor3 for groovy will conform to this
  feature set and that upgrades to the kernel version (say to 5.8) that may
  include newer AppArmor confinement features will not result in additional
  policy denials as a result (since say the existing profile did not specify
  a rule for a new AppArmor feature which is now supported by the upgraded
  kernel). This ensures that there will be no regressions in application
  behaviour as a result of AppArmor kernel feature upgrades.

  TESTING

  This has been extensively tested by the security team - this includes
  following the documented Ubuntu merges test plan[2] for AppArmor and the
  extensive QA Regression Tests[3] for AppArmor as well. This ensures that the
  various applications that make heavy use of AppArmor (LXD, docker, lxc,
  dbus, libvirt, snapd etc) have all been exercised and no regressions have
  been observed. All tests have passed and demonstrated both apparmor and the
  various applications that use it to be working as expected.

  BUILD LOGS

  This is currently uploaded to groovy-proposed, build logs can be found on
  Launchpad at:
  https://launchpad.net/ubuntu/+source/apparmor/3.0.0~beta1-0ubuntu1

  INSTALL LOG

  See attached
  
(https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+attachment/5411197/+files
  /groovy-proposed-apparmor-install.log) for a log showing install of
  the packages from groovy-proposed

  [1] https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_3.0
  [2] https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor
  [3] 
https://git.launchpad.net/qa-regression-testing/tree/scripts/test-apparmor.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : 

[Touch-packages] [Bug 1895060] Re: [FFe] apparmor 3 upstream release

2020-09-17 Thread Jamie Strandboge
FYI, the fix for the dbus issue is
https://gitlab.com/apparmor/apparmor/-/merge_requests/625. We're
preparing an ubuntu2 upload now.

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

Title:
  [FFe] apparmor 3 upstream release

Status in apparmor package in Ubuntu:
  New

Bug description:
  As per the draft upstream release notes[1]:

  AppArmor 3.0 is a major new release of the AppArmor user space that makes
  an important change to policy development and support. Its focus is
  transitioning policy to the new features ABI and as such other new features
  have been limited.

  Apprmor 3.0 is a bridge release between older AppArmor 2.x policy and the
  newer AppArmor 3 style policy which requires the declaration of a features
  abi. As such AppArmor 3.0 will be a short lived release, and will not
  receive long term support. The following AppArmor 3.1 feature release is
  planned to be a regular release, please take this into account when
  including AppArmor 3.0 into a distro release.

  As such, Ubuntu 20.10 provides a great opportunity to introduce AppArmor3
  to Ubuntu and provide these new capabilities to users and system
  administrators. The short support lifespan of Ubuntu 20.10 ensures that
  there is alignment with the limited support lifetime of AppArmor 3.0 from
  upstream, whilst giving good exposure and opportunity to test and exercise
  the new features in AppArmor 3.x on the road to Ubuntu 22.04. A highlight
  of new features provided by AppArmor 3.0 include:

  - Policy now must declare the feature abi it was developed for if it is to
    use any new features. This ensures that old policy will not become
    incompatible with new kernels that support additional AppArmor features.
  - The use of profile names that are based on pathnames are deprecated.
  - Support for new kernel features (requires appropriate features abi
    tagging in policy)
    - upstream v8 network socket rules
    - xattr attachment conditionals
    - capabilities PERFMON and BPF
  - Improved compiler warnings and semantic checks
  - aa-status rewritten in C (previously was python) with additional features
    - supports use in systems/images where python is not available
    - supports kill, unconfined and mixed profile modes
  - Rewritten aa-notify (previously was perl, now python3)
    - shared backend with other python tools
    - support use of aa.CONFDIR instead of hard coded /etc/apparmor
    - improved message layout
  - Improved support for kernels that support LSM stacking
  - New utility aa-features-abi to extract and work with kernel abi features
  - New utility aa-load to load binary policy without calling the
    apparmor_parser
  - Support for profile modes
    - enforce (default when no mode flag is supplied)
    - kill (experimental)
    - unconfined (experimental)

  The use of the new AppArmor profile feature ABI includes a default
  configuration (for the Ubuntu packaged version of AppArmor proposed in this
  FFE) for the AppArmor features within the 5.4 Linux kernel - this ensures
  that all profiles provided in AppArmor3 for groovy will conform to this
  feature set and that upgrades to the kernel version (say to 5.8) that may
  include newer AppArmor confinement features will not result in additional
  policy denials as a result (since say the existing profile did not specify
  a rule for a new AppArmor feature which is now supported by the upgraded
  kernel). This ensures that there will be no regressions in application
  behaviour as a result of AppArmor kernel feature upgrades.

  TESTING

  This has been extensively tested by the security team - this includes
  following the documented Ubuntu merges test plan[2] for AppArmor and the
  extensive QA Regression Tests[3] for AppArmor as well. This ensures that the
  various applications that make heavy use of AppArmor (LXD, docker, lxc,
  dbus, libvirt, snapd etc) have all been exercised and no regressions have
  been observed. All tests have passed and demonstrated both apparmor and the
  various applications that use it to be working as expected.

  BUILD LOGS

  This is currently uploaded to groovy-proposed, build logs can be found on
  Launchpad at:
  https://launchpad.net/ubuntu/+source/apparmor/3.0.0~beta1-0ubuntu1

  INSTALL LOG

  See attached
  
(https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+attachment/5411197/+files
  /groovy-proposed-apparmor-install.log) for a log showing install of
  the packages from groovy-proposed

  [1] https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_3.0
  [2] https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor
  [3] 
https://git.launchpad.net/qa-regression-testing/tree/scripts/test-apparmor.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+subscriptions

-- 
Mailing list: 

[Touch-packages] [Bug 1895060] Re: [FFe] apparmor 3 upstream release

2020-09-16 Thread Jamie Strandboge
FYI, we're looking at the autopkgtest dbus issue now.

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

Title:
  [FFe] apparmor 3 upstream release

Status in apparmor package in Ubuntu:
  New

Bug description:
  As per the draft upstream release notes[1]:

  AppArmor 3.0 is a major new release of the AppArmor user space that makes
  an important change to policy development and support. Its focus is
  transitioning policy to the new features ABI and as such other new features
  have been limited.

  Apprmor 3.0 is a bridge release between older AppArmor 2.x policy and the
  newer AppArmor 3 style policy which requires the declaration of a features
  abi. As such AppArmor 3.0 will be a short lived release, and will not
  receive long term support. The following AppArmor 3.1 feature release is
  planned to be a regular release, please take this into account when
  including AppArmor 3.0 into a distro release.

  As such, Ubuntu 20.10 provides a great opportunity to introduce AppArmor3
  to Ubuntu and provide these new capabilities to users and system
  administrators. The short support lifespan of Ubuntu 20.10 ensures that
  there is alignment with the limited support lifetime of AppArmor 3.0 from
  upstream, whilst giving good exposure and opportunity to test and exercise
  the new features in AppArmor 3.x on the road to Ubuntu 22.04. A highlight
  of new features provided by AppArmor 3.0 include:

  - Policy now must declare the feature abi it was developed for if it is to
    use any new features. This ensures that old policy will not become
    incompatible with new kernels that support additional AppArmor features.
  - The use of profile names that are based on pathnames are deprecated.
  - Support for new kernel features (requires appropriate features abi
    tagging in policy)
    - upstream v8 network socket rules
    - xattr attachment conditionals
    - capabilities PERFMON and BPF
  - Improved compiler warnings and semantic checks
  - aa-status rewritten in C (previously was python) with additional features
    - supports use in systems/images where python is not available
    - supports kill, unconfined and mixed profile modes
  - Rewritten aa-notify (previously was perl, now python3)
    - shared backend with other python tools
    - support use of aa.CONFDIR instead of hard coded /etc/apparmor
    - improved message layout
  - Improved support for kernels that support LSM stacking
  - New utility aa-features-abi to extract and work with kernel abi features
  - New utility aa-load to load binary policy without calling the
    apparmor_parser
  - Support for profile modes
    - enforce (default when no mode flag is supplied)
    - kill (experimental)
    - unconfined (experimental)

  The use of the new AppArmor profile feature ABI includes a default
  configuration (for the Ubuntu packaged version of AppArmor proposed in this
  FFE) for the AppArmor features within the 5.4 Linux kernel - this ensures
  that all profiles provided in AppArmor3 for groovy will conform to this
  feature set and that upgrades to the kernel version (say to 5.8) that may
  include newer AppArmor confinement features will not result in additional
  policy denials as a result (since say the existing profile did not specify
  a rule for a new AppArmor feature which is now supported by the upgraded
  kernel). This ensures that there will be no regressions in application
  behaviour as a result of AppArmor kernel feature upgrades.

  TESTING

  This has been extensively tested by the security team - this includes
  following the documented Ubuntu merges test plan[2] for AppArmor and the
  extensive QA Regression Tests[3] for AppArmor as well. This ensures that the
  various applications that make heavy use of AppArmor (LXD, docker, lxc,
  dbus, libvirt, snapd etc) have all been exercised and no regressions have
  been observed. All tests have passed and demonstrated both apparmor and the
  various applications that use it to be working as expected.

  BUILD LOGS

  This is currently uploaded to groovy-proposed, build logs can be found on
  Launchpad at:
  https://launchpad.net/ubuntu/+source/apparmor/3.0.0~beta1-0ubuntu1

  INSTALL LOG

  See attached
  
(https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+attachment/5411197/+files
  /groovy-proposed-apparmor-install.log) for a log showing install of
  the packages from groovy-proposed

  [1] https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_3.0
  [2] https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor
  [3] 
https://git.launchpad.net/qa-regression-testing/tree/scripts/test-apparmor.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net

[Touch-packages] [Bug 1880841] Re: usr.sbin.nscd needs unix socket access to @userdb-*

2020-09-09 Thread Jamie Strandboge
This will be fixed in the next apparmor upload.

** Changed in: apparmor (Ubuntu)
   Status: New => In Progress

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

Title:
  usr.sbin.nscd needs unix socket access to @userdb-*

Status in apparmor package in Ubuntu:
  In Progress

Bug description:
  This concerns apparmor-profiles 2.13.3-7ubuntu5 in Ubuntu focal.

  I use the usr.sbin.nscd profile in enforce mode, and am seeing the
  following messages in /var/log/syslog . I don't know if the SIGABRT is
  related:

  May 27 04:39:56 test-ubuntu64 kernel: [  199.392521] audit: type=1400 
audit(1590568796.975:76): apparmor="DENIED" operation="bind" profile="nscd" 
pid=1679 comm="nscd" family="unix" sock_type="dgram" protocol=0 
requested_mask="bind" denied_mask="bind" 
addr="@userdb-4a5d3fdcfb9afbd7fc75948800519358"
  May 27 04:40:17 test-ubuntu64 systemd[1]: nscd.service: Main process exited, 
code=killed, status=6/ABRT
  May 27 04:40:17 test-ubuntu64 systemd[1]: nscd.service: Failed with result 
'signal'.
  May 27 04:40:17 test-ubuntu64 systemd[1]: nscd.service: Scheduled restart 
job, restart counter is at 9.

  
  The @userdb-* binding looks like a systemd thing. Should a rule for this go 
into /etc/apparmor.d/abstractions/nameservice ?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1880841/+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 1887577] Re: DEP8: Invalid capability setuid

2020-09-09 Thread Jamie Strandboge
This will be fixed in the next apparmor upload.

** Changed in: apparmor (Ubuntu)
   Status: New => In Progress

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

Title:
  DEP8: Invalid capability setuid

Status in apparmor package in Ubuntu:
  In Progress

Bug description:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-
  groovy/groovy/amd64/a/apparmor/20200713_202347_dd214@/log.gz

  Excuses is showing apparmor failing dep8 tests when they are triggered
  by another package.

  last time apparmor was uploaded was on May 14th, and this is the
  package under test:

  https://launchpad.net/ubuntu/+source/apparmor/2.13.3-7ubuntu6

  
  The errors are like this:
  FAIL: test_profile_newer_rewrites_cache (__main__.AAParserAltCacheTests)
  --
  Traceback (most recent call last):
File "/tmp/tmp.40nJ4LqRYT/parser/tst/testlib.py", line 50, in 
new_unittest_func
  return unittest_func(self)
File "./caching.py", line 448, in test_profile_newer_rewrites_cache
  self._generate_cache_file()
File "./caching.py", line 257, in _generate_cache_file
  self.run_cmd_check(cmd)
File "/tmp/tmp.40nJ4LqRYT/parser/tst/testlib.py", line 73, in run_cmd_check
  self.assertEqual(rc, expected_rc, "Got return code %d, expected 
%d\nCommand run: %s\nOutput: %s" % (rc, expected_rc, (' '.join(command)), 
report))
  AssertionError: 1 != 0 : Got return code 1, expected 0
  Command run: ../apparmor_parser --config-file=./parser.conf --base 
/tmp/aa-caching-s3l9wndt --skip-kernel-load --cache-loc 
/tmp/aa-caching-s3l9wndt/cache --cache-loc 
/tmp/aa-caching-s3l9wndt/aa-alt-cachezi43qt78 -q --write-cache -r 
/tmp/aa-caching-s3l9wndt/sbin.pingy
  Output: AppArmor parser error for /tmp/aa-caching-s3l9wndt/sbin.pingy in 
/tmp/aa-caching-s3l9wndt/suid-abstraction at line 3: Invalid capability setuid.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1887577/+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 1889699] Re: Brave is not included in the Ubuntu helpers

2020-09-09 Thread Jamie Strandboge
Thanks for the patch! I'll get this incorporated into the next apparmor
upload.

** Changed in: apparmor (Ubuntu)
   Status: New => In Progress

** Changed in: apparmor (Ubuntu)
 Assignee: (unassigned) => Jamie Strandboge (jdstrand)

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

Title:
  Brave is not included in the Ubuntu helpers

Status in apparmor package in Ubuntu:
  In Progress

Bug description:
  The Brave browser is not included in /etc/apparmor.d/abstractions
  /ubuntu-browsers and /etc/apparmor.d/abstractions/ubuntu-helpers which
  means that when it's set as a default browser by a user, profiles like
  /etc/apparmor.d/usr.bin.evince break.

  In this case, it means that users can't click on web links in PDFs for
  example: https://community.brave.com/t/brave-does-not-open-links-
  clicked-when-set-as-default-browser/146608/9

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1889699/+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 1891338] Re: apparmor misconfigured for envice

2020-09-09 Thread Jamie Strandboge
You are right that there are two places this is defined: in
/etc/apparmor.d/abstractions/ubuntu-browsers.d/ubuntu-integration and in
/etc/apparmor.d/usr.bin.evince.

I'll adjust apparmor to fix ubuntu-integration to use the exo-open
abstraction.

There is an evince task though because we don't want it to use the
ubuntu-integration abstraction. Instead the exo-open stanza in the
usr.bin.evince should just include the exo-open abstraction. Ie, replace
this:

  # For Xubuntu to launch the browser
  /usr/bin/exo-open ixr,
  /usr/lib/@{multiarch}/xfce4/exo-1/exo-helper-1 ixr,
  /etc/xdg/xdg-xubuntu/xfce4/helpers.rc r,
  /etc/xdg/xfce4/helpers.rc r,

with this:

  # For Xubuntu to launch the browser
  #include 


** Also affects: evince (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: apparmor (Ubuntu)
   Status: New => In Progress

** Changed in: evince (Ubuntu)
   Status: New => Triaged

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

Title:
  apparmor misconfigured for envice

Status in apparmor package in Ubuntu:
  In Progress
Status in evince package in Ubuntu:
  Triaged

Bug description:
  On a fully up to date xubuntu 20-04 system, when i run evince and
  click on a link, it fails to follow that link in my browser. This kind
  of thing happens when you are reading a technical paper and want to
  follow one of the references and click on the doi or url.

  When i click on the link i get a box that i cannot copy from that says:
  Failed to launch preferred application for category "WebBrowser".

  Failed to execute child process "/usr/lib/x86_64-linux-gnu/xfce4/exo-2
  /exo-helper-2"(Permission denied).

  Did I say that it is annoying that i could not copy the text in this
  box!!

  The output of the ldd command you asked for is attached.

  I should also point out that this worked fine under xubuntu 18.04.

  I had originally posted this as an additional comment on
  https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1869159?comments=all
  but https://launchpad.net/~seb128 said that I should submit this as a
  separate bug because this is likely an apparmor configuration problem
  that is similar to the ancient bug
  https://bugs.launchpad.net/bugs/987578.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1891338/+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 1895060] [NEW] [FFe] apparmor 3 upstream release

2020-09-09 Thread Jamie Strandboge
Public bug reported:

To be filled in

** 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/1895060

Title:
  [FFe] apparmor 3 upstream release

Status in apparmor package in Ubuntu:
  New

Bug description:
  To be filled in

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+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 1385013] Re: proper fix for apparmor mediation of lower (encrypted) filesystem

2020-08-26 Thread Jamie Strandboge
I'm bumping the priority down to Undecided as its been almost 6 years--
it clearly isn't critical. :)

** Changed in: apparmor (Ubuntu)
 Assignee: NYEIN LIN THU (mgnyein) => (unassigned)

** Changed in: apparmor (Ubuntu)
   Importance: Critical => Undecided

** Changed in: ecryptfs-utils (Ubuntu)
   Importance: Critical => Undecided

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

Title:
  proper fix for apparmor mediation of lower (encrypted) filesystem

Status in apparmor package in Ubuntu:
  Confirmed
Status in ecryptfs-utils package in Ubuntu:
  Confirmed

Bug description:
  This is the proper fix for LP: #359338 which is needed for user data
  encryption.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1385013/+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 1891810] Re: Missing openat2 syscall, causes problems for fuse-overlayfs in nspawn containers

2020-08-17 Thread Jamie Strandboge
** Also affects: libseccomp (Ubuntu Groovy)
   Importance: Undecided
 Assignee: Alex Murray (alexmurray)
   Status: New

** Also affects: libseccomp (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: libseccomp (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: libseccomp (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Changed in: libseccomp (Ubuntu Focal)
 Assignee: (unassigned) => Alex Murray (alexmurray)

** Changed in: libseccomp (Ubuntu Bionic)
 Assignee: (unassigned) => Alex Murray (alexmurray)

** Changed in: libseccomp (Ubuntu Xenial)
 Assignee: (unassigned) => Alex Murray (alexmurray)

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

Title:
  Missing openat2 syscall, causes problems for fuse-overlayfs in nspawn
  containers

Status in libseccomp package in Ubuntu:
  New
Status in libseccomp source package in Xenial:
  New
Status in libseccomp source package in Bionic:
  New
Status in libseccomp source package in Focal:
  New
Status in libseccomp source package in Groovy:
  New

Bug description:
  The version of libseccomp2 in bionic does not know about the openat2
  syscall.

  In my particular usecase, I was trying to run podman/buildah in an
  nspawn container, using fuse-overlayfs. This leads to peculiar failure
  modes as described in this issue:

  https://github.com/containers/fuse-overlayfs/issues/220

  This could well cause other problems, previously issues like that have
  affected snapd, etc.

  Backporting the master branch of libseccomp fixed this for me, but for
  an SRU a cherrypick of
  
https://github.com/seccomp/libseccomp/commit/b3206ad5645dceda89538ea8acc984078ab697ab
  might be sufficient...

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: libseccomp2 2.4.3-1ubuntu3.18.04.3
  ProcVersionSignature: Ubuntu 5.4.0-42.46~18.04.1-generic 5.4.44
  Uname: Linux 5.4.0-42-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.16
  Architecture: amd64
  Date: Sun Aug 16 17:35:09 2020
  Dependencies:
   gcc-8-base 8.4.0-1ubuntu1~18.04
   libc6 2.27-3ubuntu1.2
   libgcc1 1:8.4.0-1ubuntu1~18.04
  ProcEnviron:
   TERM=screen.xterm-256color
   PATH=(custom, no user)
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: libseccomp
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1891810/+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 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2020-08-04 Thread Jamie Strandboge
I agree that a new bug should be filed. When doing so, please attach any
relevant policy violations from journalctl to the bug.

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

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

Status in ibus:
  Fix Released
Status in apparmor package in Ubuntu:
  Fix Released
Status in ibus package in Ubuntu:
  Fix Released
Status in im-config package in Ubuntu:
  Fix Released
Status in snapd package in Ubuntu:
  Fix Released
Status in apparmor source package in Xenial:
  Fix Released
Status in im-config source package in Xenial:
  Fix Released
Status in snapd source package in Xenial:
  Fix Released
Status in apparmor source package in Yakkety:
  Fix Released
Status in im-config source package in Yakkety:
  Fix Released
Status in snapd source package in Yakkety:
  Fix Released

Bug description:
  = SRU im-config =
  [Impact]
  ibus-daemon by default uses a unix socket name of /tmp/dbus-... that is 
indistinguishable from dbus-daemon abstract sockets. While dbus-daemon has 
AppArmor mediation, ibus-daemon does not so it is important that its abstract 
socket not be confused with dbus-daemon's. By modifying ibus-daemon's start 
arguments to use "--address 'unix:tmpdir=/tmp/ibus'" AppArmor can continue 
mediating DBus abstract sockets like normal and also mediate access to the 
ibus-daemon-specific abstract socket via unix rules. This also tidies up the 
abstract socket paths so that it is clear which are for ibus-daemon, which for 
dbus-daemon, etc.

  The upload simply adjusts 21_ibus.rc to start ibus-daemon with "--
  address 'unix:tmpdir=/tmp/ibus'" and adds a comment. No compiled code
  changes are required.

  [Test Case]
  1. start a unity session before updating to the package in -proposed

  2. $ grep IBUS_ADDRESS ~/.config/ibus/bus/*-unix-0
  
IBUS_ADDRESS=unix:abstract=/tmp/dbus-Vyx8fGFA,guid=28e8e7e89f902c8d4e9d77c5557add76

  3. $ lsof -p $(pidof ibus-daemon) | grep '/dbus'
  ibus-daem 2973 jamie8u unix 0x  0t0   29606 
@/tmp/dbus-oxKYpN30 type=STREAM

  4. update the package in -proposed and perform '2' and '3'. The
  IBUS_ADDRESSES should be the same as before

  5. logout of unity, then log back in

  6. $ grep IBUS_ADDRESS ~/.config/ibus/bus/*-unix-0
  
IBUS_ADDRESS=unix:abstract=/tmp/ibus/dbus-SpxOl8Fc,guid=06d4bbeb07614c6dffbf221c57473f4e

  (notice '/tmp/ibus/' in the path)

  7. $ lsof -p $(pidof ibus-daemon) | grep '/dbus'
  ibus-daem 3471 jamie8u unix 0x  0t0  26107 
@/tmp/ibus/dbus-SpxOl8Fc type=STREAM
  ...

  (notice '@/tmp/ibus/' in the path)

  In addition to the above, you can test for regressions by opening
  'System Settings' under the 'gear' icon in the panel and selecting
  'Text Entry'. From there, add an input source on the right, make sure
  'Show current input source in the menu bar' is checked, then use the
  input source panel indicator to change input sources.

  Extended test case to verify input support still works in unconfined
  and confined applications:

  1. Systems Settings Language Support, if prompted install the complete 
language support
  2. Install Chinese (simple and traditional)
  3. sudo apt-get install ibus-pinyin ibus-sunpinyin
  4. logout / login
  5. System Settings / Text Entry - add Chinese (Pinyin) (IBus)
  6. select pinyin from the indicator
  7. sudo lsof | grep ibus | grep @ # will use @/tmp/dbus-...
  8. open gnome-calculator and try to type something in (should get a pop-up)
  9. open evince and try to search a pdf (should get a pop up)
  10. upgrade apparmor and im-config from xenial-proposed
  11. logout and back in
  12. sudo lsof | grep ibus | grep @ # will use @/tmp/ibus/...
  13. open gnome-calculator and try to type something in (should get a pop-up)
  14. open evince and try to search a pdf (should get a pop up)
  15. verify no new apparmor denials

  [Regression Potential]

  The regression potential is considered low because there are no
  compiled code changes and because the changes only occur after ibus-
  daemon is restarted, which is upon session start, not package upgrade.
  When it is restarted, the files in ~/.config/ibus/bus/*-unix-0 are
  updated accordingly for other applications to pick up.

  This change intentionally requires a change to the unity7 snapd
  interface, which is in already done.

  This change intentionally requires a change to apparmor to add a unix
  rule for communicating with the new ibus address. This is in xenial-
  proposed 2.10.95-0ubuntu2.3 (and 2.10.95-0ubuntu2.4). The packages
  changes to im-config use 'Breaks: apparmor (<< 2.10.95-0ubuntu2.3) to
  ensure that the apparmor abstraction is updated and policy recompiled
  before ibus is restarted. This was omitted from the initial im-config
  upload which resulted in bug #1588197. Test cases ensuring this 

[Touch-packages] [Bug 1751677] Re: apparmor fails to start

2020-07-11 Thread Jamie Strandboge
** Project changed: apparmor => apparmor (Ubuntu)

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

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

Title:
  apparmor fails to start

Status in apparmor package in Ubuntu:
  Invalid

Bug description:
  acer@acer-Aspire-F5-573G:~$ systemctl status apparmor.service
  ● apparmor.service - AppArmor initialization
 Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor 
preset:
 Active: failed (Result: exit-code) since Mon 2018-02-26 07:32:58 +07; 9min 
ag
   Docs: man:apparmor(7)
 http://wiki.apparmor.net/
Process: 352 ExecStart=/etc/init.d/apparmor start (code=exited, status=123)
   Main PID: 352 (code=exited, status=123)

  Feb 26 07:32:57 acer-Aspire-F5-573G apparmor[352]: Skipping profile in 
/etc/appa
  Feb 26 07:32:57 acer-Aspire-F5-573G apparmor[352]: Skipping profile in 
/etc/appa
  Feb 26 07:32:57 acer-Aspire-F5-573G apparmor[352]: AppArmor parser error for 
/et
  Feb 26 07:32:57 acer-Aspire-F5-573G apparmor[352]: AppArmor parser error for 
/et
  Feb 26 07:32:57 acer-Aspire-F5-573G apparmor[352]: Skipping profile in 
/etc/appa
  Feb 26 07:32:58 acer-Aspire-F5-573G apparmor[352]:...fail!
  Feb 26 07:32:58 acer-Aspire-F5-573G systemd[1]: apparmor.service: Main 
process e
  Feb 26 07:32:58 acer-Aspire-F5-573G systemd[1]: Failed to start AppArmor 
initial
  Feb 26 07:32:58 acer-Aspire-F5-573G systemd[1]: apparmor.service: Unit 
entered f
  Feb 26 07:32:58 acer-Aspire-F5-573G systemd[1]: apparmor.service: Failed with 
re

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1751677/+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 1886115] Re: libseccomp 2.4.3-1ubuntu3.18.04.2 causes systemd to segfault on boot

2020-07-07 Thread Jamie Strandboge
This seems related:
* https://bugzilla.redhat.com/show_bug.cgi?id=1653068
* https://github.com/systemd/systemd/pull/11157

I can't say why the libseccomp update would change anything, though the
redhat bug shows an AVC denial, so I wonder if you see anything related
to systemd-resolved with 'journalctl | grep audit | grep systemd' at the
time of the boot failure. If you see a seccomp denial, that might
indicate a change in libseccomp to further investigate.

Regardless, systemd should not be crashing and
https://github.com/systemd/systemd/pull/11157 should be backported IME.

** Bug watch added: Red Hat Bugzilla #1653068
   https://bugzilla.redhat.com/show_bug.cgi?id=1653068

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

Title:
  libseccomp 2.4.3-1ubuntu3.18.04.2 causes systemd to segfault on boot

Status in libseccomp package in Ubuntu:
  Incomplete
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
After applying updates to Ubuntu 18.04 my desktop (apple mini with
  i5-2415M CPU) failed to complete the boot process.  A few seconds into
  the boot, the last message displayed is "/var mounted".  The system
  then appears to hang indefinitely.

Luckily, the 'rescue' boot image allows the boot process to proceed 
sufficiently far to allow a root shell to be spawned.  Unfortunately no log 
files were written during the unsuccessful attempts to boot.  Spawning a 2nd 
root shell (# nohup getty tty5) on a 2nd virtual terminal (tty5) I was able to 
observe the message 'systemd freezing execution' after I closed the first root 
shell and resumed the boot process.  Further a core file was created (belonging 
to /sbin/init) in the root fs
  --8<--
  (gdb) bt
  #0  0x7f16807ba187 in kill () at ../sysdeps/unix/syscall-template.S:78
  #1  0x563b957223b7 in ?? ()
  #2  
  #3  __GI___libc_free (mem=0x4a60d140dfd9a5) at malloc.c:3103
  #4  0x563b9577c22e in ?? ()
  #5  0x563b957672d6 in ?? ()
  #6  0x563b9576ba22 in ?? ()
  #7  0x563b9574f51a in ?? ()
  #8  0x7f16803a509a in ?? () from /lib/systemd/libsystemd-shared-237.so
  #9  0x7f16803a53ea in sd_event_dispatch () from 
/lib/systemd/libsystemd-shared-237.so
  #10 0x7f16803a5579 in sd_event_run () from 
/lib/systemd/libsystemd-shared-237.so
  #11 0x563b9572a49d in ?? ()
  #12 0x563b9571560c in ?? ()
  #13 0x7f168079cb97 in __libc_start_main (main=0x563b957139c0, argc=3, 
argv=0x7ffe78153758, 
  init=, fini=, rtld_fini=, 
  stack_end=0x7ffe78153748) at ../csu/libc-start.c:310
  #14 0x563b957164fa in ?? ()
  (gdb) 
  -->8--
   and the kernel message buffer lists 
  --8<--
  traps: systemd[1] general protection fault ip:7f17ebf6e98d sp:7ffd774d6020 
error:0 in libc-2.27.so[7f17ebed7000+1e7000]
  -->8--
  . 

To me that looked a bit like Bug 669702 of Gentoo
  (https://bugs.gentoo.org/669702) and indeed one of the (few) updates
  applied just prior the reboot was the update of libseccomp.

I was able to circumvent the problem by disabling (commenting out) the 
syscall filtering requested by systemd (on my system, only 
/etc/systemd/system/dbus-org.freedesktop.resolve1.service needed to be 
modified).
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.9-0ubuntu7.15
  Architecture: amd64
  CurrentDesktop: MATE
  DistroRelease: Ubuntu 18.04
  InstallationDate: Installed on 2019-03-30 (460 days ago)
  InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 
(20190210)
  MachineType: Apple Inc. Macmini5,1
  NonfreeKernelModules: wl
  Package: systemd 237-3ubuntu10.41 [modified: 
lib/systemd/system/systemd-resolved.service]
  PackageArchitecture: amd64
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.3.0-62-generic 
root=UUID=891c2e06-2b40-4e79-a57f-6e550be932bb ro recovery nomodeset
  ProcVersionSignature: Ubuntu 5.3.0-62.56~18.04.1-generic 5.3.18
  Tags:  bionic
  Uname: Linux 5.3.0-62-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dialout dip lpadmin plugdev sambashare sudo
  _MarkForUpload: True
  dmi.bios.date: 01/24/2012
  dmi.bios.vendor: Apple Inc.
  dmi.bios.version: MM51.88Z.0077.B10.1201241549
  dmi.board.asset.tag: Base Board Asset Tag#
  dmi.board.name: Mac-8ED6AF5B48C039E1
  dmi.board.vendor: Apple Inc.
  dmi.board.version: Macmini5,1
  dmi.chassis.type: 16
  dmi.chassis.vendor: Apple Inc.
  dmi.chassis.version: Mac-8ED6AF5B48C039E1
  dmi.modalias: 
dmi:bvnAppleInc.:bvrMM51.88Z.0077.B10.1201241549:bd01/24/2012:svnAppleInc.:pnMacmini5,1:pvr1.0:rvnAppleInc.:rnMac-8ED6AF5B48C039E1:rvrMacmini5,1:cvnAppleInc.:ct16:cvrMac-8ED6AF5B48C039E1:
  dmi.product.family: Macmini
  dmi.product.name: Macmini5,1
  dmi.product.sku: System SKU#
  dmi.product.version: 1.0
  dmi.sys.vendor: Apple Inc.
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.9-0ubuntu7.15
  Architecture: amd64
  CurrentDesktop: 

[Touch-packages] [Bug 1886115] Re: libseccomp 2.4.3-1ubuntu3.18.04.2 causes systemd to segfault on boot

2020-07-07 Thread Jamie Strandboge
Note that 2.4.1-0ubuntu0.18.04.2 was previously in bionic and had been
since May of 2019 (2.3.1-2.1ubuntu4 is what bionic was released with,
but later updated to 2.4.1-0ubuntu0.18.04.2). 2.4.1-0ubuntu0.18.04.2 can
be found here:
https://launchpad.net/ubuntu/+source/libseccomp/2.4.1-0ubuntu0.18.04.2

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

Title:
  libseccomp 2.4.3-1ubuntu3.18.04.2 causes systemd to segfault on boot

Status in libseccomp package in Ubuntu:
  Incomplete
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
After applying updates to Ubuntu 18.04 my desktop (apple mini with
  i5-2415M CPU) failed to complete the boot process.  A few seconds into
  the boot, the last message displayed is "/var mounted".  The system
  then appears to hang indefinitely.

Luckily, the 'rescue' boot image allows the boot process to proceed 
sufficiently far to allow a root shell to be spawned.  Unfortunately no log 
files were written during the unsuccessful attempts to boot.  Spawning a 2nd 
root shell (# nohup getty tty5) on a 2nd virtual terminal (tty5) I was able to 
observe the message 'systemd freezing execution' after I closed the first root 
shell and resumed the boot process.  Further a core file was created (belonging 
to /sbin/init) in the root fs
  --8<--
  (gdb) bt
  #0  0x7f16807ba187 in kill () at ../sysdeps/unix/syscall-template.S:78
  #1  0x563b957223b7 in ?? ()
  #2  
  #3  __GI___libc_free (mem=0x4a60d140dfd9a5) at malloc.c:3103
  #4  0x563b9577c22e in ?? ()
  #5  0x563b957672d6 in ?? ()
  #6  0x563b9576ba22 in ?? ()
  #7  0x563b9574f51a in ?? ()
  #8  0x7f16803a509a in ?? () from /lib/systemd/libsystemd-shared-237.so
  #9  0x7f16803a53ea in sd_event_dispatch () from 
/lib/systemd/libsystemd-shared-237.so
  #10 0x7f16803a5579 in sd_event_run () from 
/lib/systemd/libsystemd-shared-237.so
  #11 0x563b9572a49d in ?? ()
  #12 0x563b9571560c in ?? ()
  #13 0x7f168079cb97 in __libc_start_main (main=0x563b957139c0, argc=3, 
argv=0x7ffe78153758, 
  init=, fini=, rtld_fini=, 
  stack_end=0x7ffe78153748) at ../csu/libc-start.c:310
  #14 0x563b957164fa in ?? ()
  (gdb) 
  -->8--
   and the kernel message buffer lists 
  --8<--
  traps: systemd[1] general protection fault ip:7f17ebf6e98d sp:7ffd774d6020 
error:0 in libc-2.27.so[7f17ebed7000+1e7000]
  -->8--
  . 

To me that looked a bit like Bug 669702 of Gentoo
  (https://bugs.gentoo.org/669702) and indeed one of the (few) updates
  applied just prior the reboot was the update of libseccomp.

I was able to circumvent the problem by disabling (commenting out) the 
syscall filtering requested by systemd (on my system, only 
/etc/systemd/system/dbus-org.freedesktop.resolve1.service needed to be 
modified).
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.9-0ubuntu7.15
  Architecture: amd64
  CurrentDesktop: MATE
  DistroRelease: Ubuntu 18.04
  InstallationDate: Installed on 2019-03-30 (460 days ago)
  InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 
(20190210)
  MachineType: Apple Inc. Macmini5,1
  NonfreeKernelModules: wl
  Package: systemd 237-3ubuntu10.41 [modified: 
lib/systemd/system/systemd-resolved.service]
  PackageArchitecture: amd64
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.3.0-62-generic 
root=UUID=891c2e06-2b40-4e79-a57f-6e550be932bb ro recovery nomodeset
  ProcVersionSignature: Ubuntu 5.3.0-62.56~18.04.1-generic 5.3.18
  Tags:  bionic
  Uname: Linux 5.3.0-62-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dialout dip lpadmin plugdev sambashare sudo
  _MarkForUpload: True
  dmi.bios.date: 01/24/2012
  dmi.bios.vendor: Apple Inc.
  dmi.bios.version: MM51.88Z.0077.B10.1201241549
  dmi.board.asset.tag: Base Board Asset Tag#
  dmi.board.name: Mac-8ED6AF5B48C039E1
  dmi.board.vendor: Apple Inc.
  dmi.board.version: Macmini5,1
  dmi.chassis.type: 16
  dmi.chassis.vendor: Apple Inc.
  dmi.chassis.version: Mac-8ED6AF5B48C039E1
  dmi.modalias: 
dmi:bvnAppleInc.:bvrMM51.88Z.0077.B10.1201241549:bd01/24/2012:svnAppleInc.:pnMacmini5,1:pvr1.0:rvnAppleInc.:rnMac-8ED6AF5B48C039E1:rvrMacmini5,1:cvnAppleInc.:ct16:cvrMac-8ED6AF5B48C039E1:
  dmi.product.family: Macmini
  dmi.product.name: Macmini5,1
  dmi.product.sku: System SKU#
  dmi.product.version: 1.0
  dmi.sys.vendor: Apple Inc.
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.9-0ubuntu7.15
  Architecture: amd64
  CurrentDesktop: MATE
  Dependencies:
   gcc-8-base 8.4.0-1ubuntu1~18.04
   libc6 2.27-3ubuntu1
   libgcc1 1:8.4.0-1ubuntu1~18.04
  DistroRelease: Ubuntu 18.04
  InstallationDate: Installed on 2019-03-30 (460 days ago)
  InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 
(20190210)
  NonfreeKernelModules: wl
  Package: libseccomp2 2.4.3-1ubuntu3.18.04.2
  PackageArchitecture: 

[Touch-packages] [Bug 1413410] Re: Unable to match embedded NULLs in unix bind rule for abstract sockets

2020-06-23 Thread Jamie Strandboge
We released UC16/xenial with a new enough apparmor (which was also
backported to trusty) so we can mark the snapd task as Invalid, which I
did just now.

** Changed in: snappy
   Status: Incomplete => Invalid

** Changed in: snappy
 Assignee: Jamie Strandboge (jdstrand) => (unassigned)

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

Title:
  Unable to match embedded NULLs in unix bind rule for abstract sockets

Status in AppArmor:
  Fix Released
Status in AppArmor 2.9 series:
  In Progress
Status in Snappy:
  Invalid
Status in apparmor package in Ubuntu:
  Fix Released

Bug description:
  On Ubuntu 14.10, I had this in my logs:
  Jan 21 16:32:30 localhost kernel: [24900.927939] audit: type=1400 
audit(1421879550.441:534): apparmor="DENIED" operation="bind" 
profile="/usr/lib/firefox/firefox{,*[^s][^h]}" pid=12356 comm="plugin-containe" 
family="unix" sock_type="dgram" protocol=0 requested_mask="bind" 
denied_mask="bind" 
addr="@676F6F676C652D6E61636C2D6F316431323335362D33393100"

  $ aa-decode 
676F6F676C652D6E61636C2D6F316431323335362D33393100
  Decoded: google-nacl-o1d12356-391

  $ aa-decode 676F6F676C652D6E61636C2D6
  Decoded: google-nacl-`

  So I tried the following:
  unix bind type=dgram addr=@google-nacl*,
  unix bind type=dgram addr="@google-nacl*",
  unix bind type=dgram addr=@676F6F676C652D6E61636C2D6*,
  unix bind type=dgram addr="@676F6F676C652D6E61636C2D6*",
  unix bind type=dgram addr=@google-nacl*\\000*,
  unix bind type=dgram 
addr=@google-nacl*[0-9a-zA-Z]\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000{,\\000,\\000\\000},

  
  but none of them match. The best I could do was:
  unix bind type=dgram,

  This is likely going to be important for snappy since snappy will have the 
concept of different coordinating snaps interacting via abstract sockets. What 
is interesting is that this seems to work ok for some things, eg:
  ./lightdm:  unix (bind, listen) type=stream 
addr="@/com/ubuntu/upstart-session/**",
  ./lightdm:  unix (bind, listen) type=stream addr="@/tmp/dbus-*",
  ./lightdm:  unix (bind, listen) type=stream addr="@/tmp/.ICE-unix/[0-9]*",
  ./lightdm:  unix (bind, listen) type=stream addr="@/dbus-vfs-daemon/*",
  ./lightdm:  unix (bind, listen) type=stream addr="@guest*",

  Is this something in how firefox is setting up the socket?

  To reproduce, enable the firefox profile, start firefox and try to
  attend a google hangout.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1413410/+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 1872106] Re: isc-dhcp-server crashing constantly [Ubuntu 20.04]

2020-06-15 Thread Jamie Strandboge
@mm - that probably isn't the issue, but you can adjust
/etc/apparmor.d/local/usr.sbin.dhcpd to have:

@{PROC}/sys/net/ipv4/ip_local_port_range r,

and then do: sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.dhcpd #
yes, without local/

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

Title:
  isc-dhcp-server crashing constantly [Ubuntu 20.04]

Status in isc-dhcp package in Ubuntu:
  Confirmed

Bug description:
  isc-dhcp-server crashing constantly (sometimes within seconds or minutes, 
sometimes within hours) with the following error messages:
  Apr 10 17:45:25 xxx dhcpd[140823]: Server starting service.
  Apr 10 17:45:25 xxx sh[140823]: ../../../../lib/isc/unix/socket.c:3361: 
INSIST(!sock->pending_send) failed, back trace
  Apr 10 17:45:25 xxx sh[140823]: #0 0x7f3362f59a4a in ??
  Apr 10 17:45:25 xxx sh[140823]: #1 0x7f3362f59980 in ??
  Apr 10 17:45:25 xxx sh[140823]: #2 0x7f3362f957e1 in ??
  Apr 10 17:45:25 xxx sh[140823]: #3 0x7f3362d3c609 in ??
  Apr 10 17:45:25 xxx sh[140823]: #4 0x7f3362e78103 in ??
  Apr 10 17:45:25 xxx systemd[1]: isc-dhcp-server.service: Main process exited, 
code=killed, status=6/ABRT
  Apr 10 17:45:25 xxx systemd[1]: isc-dhcp-server.service: Failed with result 
'signal'.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1872106/+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 1882484] Re: Firewall rule in before.rules for dhcp is wrong

2020-06-15 Thread Jamie Strandboge
Marking as Invalid since the default firewall policy is working as
intended.

** Changed in: ufw (Ubuntu)
   Status: New => Invalid

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

Title:
  Firewall rule in before.rules for dhcp is wrong

Status in ufw package in Ubuntu:
  Invalid

Bug description:
  The file delivered - /usr/share/ufw/iptables/before.rules
  which is then copied to - /etc/ufw/before.rules

  Delivered by Package:

  # allow dhcp client to work
  -A ufw-before-input -p udp --sport 67 --dport 68 -j ACCEPT

  The ports for
  --sport and --dport are swapped

  Should be:

  -A ufw-before-input -p udp --sport 68 --dport 67 -j ACCEPT

  
  Package version found in:
0.36-0ubuntu0.1

  
  Note: ISC DHCP uses RAW sockets, which bypasses iptables anyway and doesn't 
drop the packets with the incorrect configuration. This has had me stumped for 
the last hour.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1882484/+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 1882484] Re: Firewall rule in before.rules for dhcp is wrong

2020-06-15 Thread Jamie Strandboge
Thank you for filing a bug.

The firewall policy is a combination of the default policy for each of
'incoming', 'outgoing' and 'routed' (forward) along with the policies
shipped in before{,6}.rules, after{,6}.rules and whatever gets added to
user{,6}.rules. Specifically, what is in before{,6}.rules is designed
with default deny for incoming (and forward), default allow for outgoing
and default accept for established connections. Considering that dhcp
uses port 68/udp for the client and port 67/udp for the server, the
shipped default policy allows:

* outgoing from this host port 68/udp to any port 67/udp (via default allow 
outgoing; eg, for dhcp request)
* incoming for established connection (via before.rules RELATED,ESTABLISHED; 
eg, dhcp reply from the server we connected to on port 67/udp)
* incoming from port 67/udp (via the before.rules you mentioned; eg, for a 
server responding to the broadcast)

I suspect that you've updated your default policy to deny to perform
egress filtering so you need to add a corresponding 'ufw allow out to
any port 67 proto udp comment "dhcp discover"' rule or similar.

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

Title:
  Firewall rule in before.rules for dhcp is wrong

Status in ufw package in Ubuntu:
  Invalid

Bug description:
  The file delivered - /usr/share/ufw/iptables/before.rules
  which is then copied to - /etc/ufw/before.rules

  Delivered by Package:

  # allow dhcp client to work
  -A ufw-before-input -p udp --sport 67 --dport 68 -j ACCEPT

  The ports for
  --sport and --dport are swapped

  Should be:

  -A ufw-before-input -p udp --sport 68 --dport 67 -j ACCEPT

  
  Package version found in:
0.36-0ubuntu0.1

  
  Note: ISC DHCP uses RAW sockets, which bypasses iptables anyway and doesn't 
drop the packets with the incorrect configuration. This has had me stumped for 
the last hour.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1882484/+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 1882314] Re: Firewall rule in before6.rules for dhcp6 is wrong

2020-06-15 Thread Jamie Strandboge
Marking as Invalid since the default firewall policy is working as
intended.

** Changed in: ufw (Ubuntu)
   Status: New => Invalid

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

Title:
  Firewall rule in before6.rules for dhcp6 is wrong

Status in ufw package in Ubuntu:
  Invalid

Bug description:
  When running DHCPv6, clients are not able get IP address.
  The firewall rule in ip6table is incorrect, and not allowing client requests 
in. The ports need to be swapped and the dst address needs to be removed, as 
it's a broadcast

  The file delivered - /usr/share/ufw/iptables/before6.rules
  which is then copied to - /etc/ufw/before6.rules

  Delivered by Package:

  # allow dhcp client to work
  -A ufw6-before-input -p udp -s fe80::/10 --sport 547 -d fe80::/10 --dport 546 
-j ACCEPT

  The ports for
  --sport and --dport are swapped
  -d fe80::/10 needs to be removed

  Should be:

  -A ufw6-before-input -p udp -s fe80::/10 --sport 546 --dport 547 -j
  ACCEPT

  Package version found in:
    0.36-0ubuntu0.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1882314/+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 1882314] Re: Firewall rule in before6.rules for dhcp6 is wrong

2020-06-15 Thread Jamie Strandboge
Thank you for filing a bug.

The firewall policy is a combination of the default policy for each of
'incoming', 'outgoing' and 'routed' (forward) along with the policies
shipped in before{,6}.rules, after{,6}.rules and whatever gets added to
user{,6}.rules. Specifically, what is in before{,6}.rules is designed
with default deny for incoming (and forward), default allow for outgoing
and default accept for established connections. Considering that dhcpv6
uses port 546/udp for the client and port 547/udp for the server, the
shipped default policy allows:

* outgoing from this host port 546/udp to any port 547/udp (via default allow 
outgoing; eg, for dhcp request)
* incoming for established connection (via before6.rules RELATED,ESTABLISHED; 
eg, dhcp reply from the server we connected to on port 547/udp)
* incoming from fe80::/10 port 547/udp (via the before6.rules you mentioned; 
eg, for a server responding to the broadcast)

I suspect that you've updated your default policy to deny to perform
egress filtering so you need to add a corresponding 'ufw allow out to
ff02::1:2 port 547 proto udp comment "dhcpv6 solicit"' rule or similar.

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

Title:
  Firewall rule in before6.rules for dhcp6 is wrong

Status in ufw package in Ubuntu:
  Invalid

Bug description:
  When running DHCPv6, clients are not able get IP address.
  The firewall rule in ip6table is incorrect, and not allowing client requests 
in. The ports need to be swapped and the dst address needs to be removed, as 
it's a broadcast

  The file delivered - /usr/share/ufw/iptables/before6.rules
  which is then copied to - /etc/ufw/before6.rules

  Delivered by Package:

  # allow dhcp client to work
  -A ufw6-before-input -p udp -s fe80::/10 --sport 547 -d fe80::/10 --dport 546 
-j ACCEPT

  The ports for
  --sport and --dport are swapped
  -d fe80::/10 needs to be removed

  Should be:

  -A ufw6-before-input -p udp -s fe80::/10 --sport 546 --dport 547 -j
  ACCEPT

  Package version found in:
    0.36-0ubuntu0.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1882314/+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 1876055] Re: SRU: Backport 2.4.3-1ubuntu3 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base and test suite robustness

2020-06-10 Thread Jamie Strandboge
Sorry, I reran bionic and *focal* autopkgtests and there are now no
regressions. Running eoan again.

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

Title:
  SRU: Backport 2.4.3-1ubuntu3 from groovy to focal/eoan/bionic/xenial
  for newer syscalls for core20 base and test suite robustness

Status in libseccomp package in Ubuntu:
  Fix Released
Status in libseccomp source package in Xenial:
  Fix Committed
Status in libseccomp source package in Bionic:
  Fix Committed
Status in libseccomp source package in Eoan:
  Fix Committed
Status in libseccomp source package in Focal:
  Fix Committed
Status in libseccomp source package in Groovy:
  Fix Released

Bug description:
  [Impact]

  The combination of snap-confine and snap-seccomp from snapd uses
  libseccomp to filter various system calls for confinement. The current
  version in eoan/bionic/xenial (2.4.1) is missing knowledge of various
  system calls for various architectures. As such this causes strange
  issues like python snaps segfaulting
  (https://github.com/snapcore/core20/issues/48) or the inadvertent
  denial of system calls which should be permitted by the base policy
  (https://forum.snapcraft.io/t/getrlimit-blocked-by-seccomp-on-focal-
  arm64/17237).

  libseccomp in groovy is using the latest upstream base release (2.4.3)
  plus it includes a patch to add some missing aarch64 system calls
  (https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1877633).

  SRUing this version back to older stable releases allows libseccomp to
  operate correctly on all supported architectures.

  
  Included as part of this SRU are test-suite reliability improvements - 
currently the xenial libseccomp package overrides test-suite failures at build 
time to ignore failures. This masks the fact that on ppc64el and s390x there 
are currently test suite failures at build time for xenial - these failures 
occur since libseccomp now includes knowledge of system calls for these 
architectures but which the linux-libc-dev package for xenial does not actually 
define (since this is based of the 4.4 kernel in xenial whereas libseccomp 
2.4.1 in xenial has knowledge of all system calls up to 5.4). 

  In this SRU I have instead fixed the test suite failures for xenial by
  including a local (test-suite specific) set of architecture specific
  kernel headers from the linux-libc-dev in focal for all releases.
  These are just the headers which define the system call numbers for
  each architecture *and* these are added to tests/include/$ARCH in the
  source package (and tests/Makefile.am is then updated to include these
  new headers only).  As such this ensures the actual build of
  libseccomp or any of the tools does not reference these headers. This
  allows the test suite in libseccomp to then be aware of theses system
  calls and so all unit tests for all architectures now pass.

  In any future updates for libseccomp to add new system calls, we can
  then similarly update these local headers to ensure the unit tests
  continue to work as expected.

  
  [Test Case]

  libseccomp includes a significant unit test suite that is run during
  the build and as part of autopkgtests. To verify the new aarch64
  system calls are resolved as expected the scmp_sys_resolver command
  can be used as well:

  $ scmp_sys_resolver -a aarch64 getrlimit
  163

  (whereas in the current version in focal this returns -10180 as
  libseccomp was not aware of this system-call at compile-time).

  As part of this SRU, the test suite in libseccomp has been patched to
  include a local copy of the architecture-specific kernel headers from
  the 5.4 kernel in focal *for all releases*, so that all system calls
  which are defined for the 5.4 kernel are known about *for the
  libseccomp test suite*. This allows all unit tests to pass on older
  releases as well and defaults the build to fail on unit test failures
  (whereas currently in xenial this has been overridden to ignore
  failures).

  
  [Regression Potential]

  This has a low regression potential due to significant testing with
  many packages that depend on libseccomp (lxc, qemu, snapd, apt, man
  etc) and none have shown any regression using this new version. The
  re-enablement of build failure on test failure at build time also
  ensures that we can reliably detect FTBFS issues in the future.

  No symbols have been removed (or added) with this update in version so
  there is no chance of regression due to ABI change etc. In the past,
  the security team has performed more significant version upgrades for
  libseccomp (2.2, 2.3, 2.4) -> 2.4.1 without major incident. In the
  case of *this* SRU, we are only doing a micro-version upgrade from
  2.4.1 to 2.4.3 so this carries even less change of regressions.

  Any possible regressions may include applications now seeing correct
  system call 

[Touch-packages] [Bug 1876055] Re: SRU: Backport 2.4.3-1ubuntu3 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base and test suite robustness

2020-06-10 Thread Jamie Strandboge
FYI, I reran the bionic and eoan autopkgtests and there are now no
regressions.

** Tags removed: verification-needed-bionic verification-needed-eoan 
verification-needed-focal verification-needed-xenial
** Tags added: verification-done-bionic verification-done-eoan 
verification-done-focal verification-done-xenial

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

Title:
  SRU: Backport 2.4.3-1ubuntu3 from groovy to focal/eoan/bionic/xenial
  for newer syscalls for core20 base and test suite robustness

Status in libseccomp package in Ubuntu:
  Fix Released
Status in libseccomp source package in Xenial:
  Fix Committed
Status in libseccomp source package in Bionic:
  Fix Committed
Status in libseccomp source package in Eoan:
  Fix Committed
Status in libseccomp source package in Focal:
  Fix Committed
Status in libseccomp source package in Groovy:
  Fix Released

Bug description:
  [Impact]

  The combination of snap-confine and snap-seccomp from snapd uses
  libseccomp to filter various system calls for confinement. The current
  version in eoan/bionic/xenial (2.4.1) is missing knowledge of various
  system calls for various architectures. As such this causes strange
  issues like python snaps segfaulting
  (https://github.com/snapcore/core20/issues/48) or the inadvertent
  denial of system calls which should be permitted by the base policy
  (https://forum.snapcraft.io/t/getrlimit-blocked-by-seccomp-on-focal-
  arm64/17237).

  libseccomp in groovy is using the latest upstream base release (2.4.3)
  plus it includes a patch to add some missing aarch64 system calls
  (https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1877633).

  SRUing this version back to older stable releases allows libseccomp to
  operate correctly on all supported architectures.

  
  Included as part of this SRU are test-suite reliability improvements - 
currently the xenial libseccomp package overrides test-suite failures at build 
time to ignore failures. This masks the fact that on ppc64el and s390x there 
are currently test suite failures at build time for xenial - these failures 
occur since libseccomp now includes knowledge of system calls for these 
architectures but which the linux-libc-dev package for xenial does not actually 
define (since this is based of the 4.4 kernel in xenial whereas libseccomp 
2.4.1 in xenial has knowledge of all system calls up to 5.4). 

  In this SRU I have instead fixed the test suite failures for xenial by
  including a local (test-suite specific) set of architecture specific
  kernel headers from the linux-libc-dev in focal for all releases.
  These are just the headers which define the system call numbers for
  each architecture *and* these are added to tests/include/$ARCH in the
  source package (and tests/Makefile.am is then updated to include these
  new headers only).  As such this ensures the actual build of
  libseccomp or any of the tools does not reference these headers. This
  allows the test suite in libseccomp to then be aware of theses system
  calls and so all unit tests for all architectures now pass.

  In any future updates for libseccomp to add new system calls, we can
  then similarly update these local headers to ensure the unit tests
  continue to work as expected.

  
  [Test Case]

  libseccomp includes a significant unit test suite that is run during
  the build and as part of autopkgtests. To verify the new aarch64
  system calls are resolved as expected the scmp_sys_resolver command
  can be used as well:

  $ scmp_sys_resolver -a aarch64 getrlimit
  163

  (whereas in the current version in focal this returns -10180 as
  libseccomp was not aware of this system-call at compile-time).

  As part of this SRU, the test suite in libseccomp has been patched to
  include a local copy of the architecture-specific kernel headers from
  the 5.4 kernel in focal *for all releases*, so that all system calls
  which are defined for the 5.4 kernel are known about *for the
  libseccomp test suite*. This allows all unit tests to pass on older
  releases as well and defaults the build to fail on unit test failures
  (whereas currently in xenial this has been overridden to ignore
  failures).

  
  [Regression Potential]

  This has a low regression potential due to significant testing with
  many packages that depend on libseccomp (lxc, qemu, snapd, apt, man
  etc) and none have shown any regression using this new version. The
  re-enablement of build failure on test failure at build time also
  ensures that we can reliably detect FTBFS issues in the future.

  No symbols have been removed (or added) with this update in version so
  there is no chance of regression due to ABI change etc. In the past,
  the security team has performed more significant version upgrades for
  libseccomp (2.2, 2.3, 2.4) -> 2.4.1 without major incident. In the
  

[Touch-packages] [Bug 1877633] Re: libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the getrlimit syscall on arm64

2020-06-10 Thread Jamie Strandboge
FYI, I reran the bionic and eoan autopkgtests and there are now no
regressions.

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

Title:
  libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the
  getrlimit syscall on arm64

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

Bug description:
  This was reported via the snapcraft forum[1]:

  On bionic amd64, libseccomp 2.4.1-0ubuntu0.18.04.2

  $ lsb_release -d
  Description:  Ubuntu 18.04.4 LTS
  $ scmp_sys_resolver -a aarch64 163
  getrlimit
  $ scmp_sys_resolver -a aarch64 getrlimit
  163

  focal amd64, libseccomp 2.4.3-1ubuntu1 -- *__BROKEN__*

  $ lsb_release -d
  Description:  Ubuntu 20.04 LTS
  $ scmp_sys_resolver -a aarch64 163
  UNKNOWN
  $ scmp_sys_resolver -a aarch64 getrlimit
  -10180

  [1]https://forum.snapcraft.io/t/getrlimit-blocked-by-seccomp-on-focal-
  arm64/17237/8

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1877633/+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 1877633] Re: libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the getrlimit syscall on arm64

2020-06-10 Thread Jamie Strandboge
Sorry, I reran bionic and *focal* autopkgtests and there are now no
regressions. Running eoan again.

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

Title:
  libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the
  getrlimit syscall on arm64

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

Bug description:
  This was reported via the snapcraft forum[1]:

  On bionic amd64, libseccomp 2.4.1-0ubuntu0.18.04.2

  $ lsb_release -d
  Description:  Ubuntu 18.04.4 LTS
  $ scmp_sys_resolver -a aarch64 163
  getrlimit
  $ scmp_sys_resolver -a aarch64 getrlimit
  163

  focal amd64, libseccomp 2.4.3-1ubuntu1 -- *__BROKEN__*

  $ lsb_release -d
  Description:  Ubuntu 20.04 LTS
  $ scmp_sys_resolver -a aarch64 163
  UNKNOWN
  $ scmp_sys_resolver -a aarch64 getrlimit
  -10180

  [1]https://forum.snapcraft.io/t/getrlimit-blocked-by-seccomp-on-focal-
  arm64/17237/8

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1877633/+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 1861177] Re: seccomp_rule_add is very slow

2020-06-10 Thread Jamie Strandboge
There isn't a snapd task (snap-seccomp is compiled against libseccomp
but it can't influence this behavior), so unassigning Ian and marking
that task as Invalid.

** Changed in: snapd
   Status: Triaged => Invalid

** Changed in: snapd
 Assignee: Ian Johnson (anonymouse67) => (unassigned)

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

Title:
  seccomp_rule_add is very slow

Status in snapd:
  Invalid
Status in libseccomp package in Ubuntu:
  In Progress

Bug description:
  There is a known and patched issue with version 2.4 of libseccomp
  where certain operations have a large performance regression. This is
  causing some packages that use libseccomp such as container
  orchestration systems to occasionally time out or otherwise fail under
  certain workloads.

  Please consider porting the patch into the various Ubuntu versions
  that have version 2.4 of libseccomp and into the backports. The
  performance patch from version 2.5 (yet to be released) applies
  cleanly on top of the 2.4 branch of libseccomp.

  For more information, and for a copy of the patch (which can also be
  cherry picked from the upstream libseccomp repos) see the similar
  Debian issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913

To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1861177/+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 1877633] Re: libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the getrlimit syscall on arm64

2020-06-10 Thread Jamie Strandboge
FYI, I reran the xenial autopkgtests and they now pass.

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

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

Title:
  libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the
  getrlimit syscall on arm64

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

Bug description:
  This was reported via the snapcraft forum[1]:

  On bionic amd64, libseccomp 2.4.1-0ubuntu0.18.04.2

  $ lsb_release -d
  Description:  Ubuntu 18.04.4 LTS
  $ scmp_sys_resolver -a aarch64 163
  getrlimit
  $ scmp_sys_resolver -a aarch64 getrlimit
  163

  focal amd64, libseccomp 2.4.3-1ubuntu1 -- *__BROKEN__*

  $ lsb_release -d
  Description:  Ubuntu 20.04 LTS
  $ scmp_sys_resolver -a aarch64 163
  UNKNOWN
  $ scmp_sys_resolver -a aarch64 getrlimit
  -10180

  [1]https://forum.snapcraft.io/t/getrlimit-blocked-by-seccomp-on-focal-
  arm64/17237/8

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1877633/+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 1876055] Re: SRU: Backport 2.4.3-1ubuntu3 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base and test suite robustness

2020-06-10 Thread Jamie Strandboge
FYI, I reran the xenial autopkgtests and there are now no regressions.

** Tags removed: verification-done-bionic verification-done-eoan 
verification-done-focal verification-done-xenial
** Tags added: verification-needed-bionic verification-needed-eoan 
verification-needed-focal verification-needed-xenial

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

Title:
  SRU: Backport 2.4.3-1ubuntu3 from groovy to focal/eoan/bionic/xenial
  for newer syscalls for core20 base and test suite robustness

Status in libseccomp package in Ubuntu:
  Fix Released
Status in libseccomp source package in Xenial:
  Fix Committed
Status in libseccomp source package in Bionic:
  Fix Committed
Status in libseccomp source package in Eoan:
  Fix Committed
Status in libseccomp source package in Focal:
  Fix Committed
Status in libseccomp source package in Groovy:
  Fix Released

Bug description:
  [Impact]

  The combination of snap-confine and snap-seccomp from snapd uses
  libseccomp to filter various system calls for confinement. The current
  version in eoan/bionic/xenial (2.4.1) is missing knowledge of various
  system calls for various architectures. As such this causes strange
  issues like python snaps segfaulting
  (https://github.com/snapcore/core20/issues/48) or the inadvertent
  denial of system calls which should be permitted by the base policy
  (https://forum.snapcraft.io/t/getrlimit-blocked-by-seccomp-on-focal-
  arm64/17237).

  libseccomp in groovy is using the latest upstream base release (2.4.3)
  plus it includes a patch to add some missing aarch64 system calls
  (https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1877633).

  SRUing this version back to older stable releases allows libseccomp to
  operate correctly on all supported architectures.

  
  Included as part of this SRU are test-suite reliability improvements - 
currently the xenial libseccomp package overrides test-suite failures at build 
time to ignore failures. This masks the fact that on ppc64el and s390x there 
are currently test suite failures at build time for xenial - these failures 
occur since libseccomp now includes knowledge of system calls for these 
architectures but which the linux-libc-dev package for xenial does not actually 
define (since this is based of the 4.4 kernel in xenial whereas libseccomp 
2.4.1 in xenial has knowledge of all system calls up to 5.4). 

  In this SRU I have instead fixed the test suite failures for xenial by
  including a local (test-suite specific) set of architecture specific
  kernel headers from the linux-libc-dev in focal for all releases.
  These are just the headers which define the system call numbers for
  each architecture *and* these are added to tests/include/$ARCH in the
  source package (and tests/Makefile.am is then updated to include these
  new headers only).  As such this ensures the actual build of
  libseccomp or any of the tools does not reference these headers. This
  allows the test suite in libseccomp to then be aware of theses system
  calls and so all unit tests for all architectures now pass.

  In any future updates for libseccomp to add new system calls, we can
  then similarly update these local headers to ensure the unit tests
  continue to work as expected.

  
  [Test Case]

  libseccomp includes a significant unit test suite that is run during
  the build and as part of autopkgtests. To verify the new aarch64
  system calls are resolved as expected the scmp_sys_resolver command
  can be used as well:

  $ scmp_sys_resolver -a aarch64 getrlimit
  163

  (whereas in the current version in focal this returns -10180 as
  libseccomp was not aware of this system-call at compile-time).

  As part of this SRU, the test suite in libseccomp has been patched to
  include a local copy of the architecture-specific kernel headers from
  the 5.4 kernel in focal *for all releases*, so that all system calls
  which are defined for the 5.4 kernel are known about *for the
  libseccomp test suite*. This allows all unit tests to pass on older
  releases as well and defaults the build to fail on unit test failures
  (whereas currently in xenial this has been overridden to ignore
  failures).

  
  [Regression Potential]

  This has a low regression potential due to significant testing with
  many packages that depend on libseccomp (lxc, qemu, snapd, apt, man
  etc) and none have shown any regression using this new version. The
  re-enablement of build failure on test failure at build time also
  ensures that we can reliably detect FTBFS issues in the future.

  No symbols have been removed (or added) with this update in version so
  there is no chance of regression due to ABI change etc. In the past,
  the security team has performed more significant version upgrades for
  libseccomp (2.2, 2.3, 2.4) -> 2.4.1 without major incident. In the
  case of 

[Touch-packages] [Bug 1877633] Re: libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the getrlimit syscall on arm64

2020-06-10 Thread Jamie Strandboge
FYI, I copied xenial-focal from the security-proposed ppa to -proposed.
Borrowing from the ubuntu-sru team's SRU verification text:

Please help us by testing this new package. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed. Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-
needed- to verification-done-. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed-. In either case, without details of your
testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.


** Changed in: libseccomp (Ubuntu Focal)
   Status: In Progress => Fix Committed

** Tags added: verification-done-focal

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

Title:
  libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the
  getrlimit syscall on arm64

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

Bug description:
  This was reported via the snapcraft forum[1]:

  On bionic amd64, libseccomp 2.4.1-0ubuntu0.18.04.2

  $ lsb_release -d
  Description:  Ubuntu 18.04.4 LTS
  $ scmp_sys_resolver -a aarch64 163
  getrlimit
  $ scmp_sys_resolver -a aarch64 getrlimit
  163

  focal amd64, libseccomp 2.4.3-1ubuntu1 -- *__BROKEN__*

  $ lsb_release -d
  Description:  Ubuntu 20.04 LTS
  $ scmp_sys_resolver -a aarch64 163
  UNKNOWN
  $ scmp_sys_resolver -a aarch64 getrlimit
  -10180

  [1]https://forum.snapcraft.io/t/getrlimit-blocked-by-seccomp-on-focal-
  arm64/17237/8

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1877633/+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 1876055] Re: SRU: Backport 2.4.3-1ubuntu3 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base and test suite robustness

2020-06-09 Thread Jamie Strandboge
FYI, I copied xenial-focal from the security-proposed ppa to -proposed.
Borrowing from the ubuntu-sru team's SRU verification text:

Please help us by testing this new package. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed. Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-
needed- to verification-done-. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed-. In either case, without details of your
testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: libseccomp (Ubuntu Xenial)
   Status: Confirmed => Fix Committed

** Changed in: libseccomp (Ubuntu Bionic)
   Status: Confirmed => Fix Committed

** Changed in: libseccomp (Ubuntu Eoan)
   Status: Confirmed => Fix Committed

** Changed in: libseccomp (Ubuntu Focal)
   Status: Confirmed => Fix Committed

** Tags added: verification-needed-bionic verification-needed-eoan
verification-needed-focal verification-needed-xenial

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

Title:
  SRU: Backport 2.4.3-1ubuntu3 from groovy to focal/eoan/bionic/xenial
  for newer syscalls for core20 base and test suite robustness

Status in libseccomp package in Ubuntu:
  Fix Released
Status in libseccomp source package in Xenial:
  Fix Committed
Status in libseccomp source package in Bionic:
  Fix Committed
Status in libseccomp source package in Eoan:
  Fix Committed
Status in libseccomp source package in Focal:
  Fix Committed
Status in libseccomp source package in Groovy:
  Fix Released

Bug description:
  [Impact]

  The combination of snap-confine and snap-seccomp from snapd uses
  libseccomp to filter various system calls for confinement. The current
  version in eoan/bionic/xenial (2.4.1) is missing knowledge of various
  system calls for various architectures. As such this causes strange
  issues like python snaps segfaulting
  (https://github.com/snapcore/core20/issues/48) or the inadvertent
  denial of system calls which should be permitted by the base policy
  (https://forum.snapcraft.io/t/getrlimit-blocked-by-seccomp-on-focal-
  arm64/17237).

  libseccomp in groovy is using the latest upstream base release (2.4.3)
  plus it includes a patch to add some missing aarch64 system calls
  (https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1877633).

  SRUing this version back to older stable releases allows libseccomp to
  operate correctly on all supported architectures.

  
  Included as part of this SRU are test-suite reliability improvements - 
currently the xenial libseccomp package overrides test-suite failures at build 
time to ignore failures. This masks the fact that on ppc64el and s390x there 
are currently test suite failures at build time for xenial - these failures 
occur since libseccomp now includes knowledge of system calls for these 
architectures but which the linux-libc-dev package for xenial does not actually 
define (since this is based of the 4.4 kernel in xenial whereas libseccomp 
2.4.1 in xenial has knowledge of all system calls up to 5.4). 

  In this SRU I have instead fixed the test suite failures for xenial by
  including a local (test-suite specific) set of architecture specific
  kernel headers from the linux-libc-dev in focal for all releases.
  These are just the headers which define the system call numbers for
  each architecture *and* these are added to tests/include/$ARCH in the
  source package (and tests/Makefile.am is then updated to include these
  new headers only).  As such this ensures the actual build of
  libseccomp or any of the tools does not reference these headers. This
  allows the test suite in libseccomp to then be aware of theses system
  calls and so all unit tests for all architectures now pass.

  In any future updates for libseccomp to add new system calls, we can
  then similarly update these local headers to ensure the unit tests
  continue to work as expected.

  
  [Test Case]

  libseccomp includes a significant unit test suite that is run during
  the build and as part of autopkgtests. To verify the new aarch64
  system calls are resolved as expected the scmp_sys_resolver command
  can be used as well:

  $ scmp_sys_resolver -a aarch64 getrlimit
  163

  (whereas in the current 

[Touch-packages] [Bug 1861177] Re: seccomp_rule_add is very slow

2020-06-09 Thread Jamie Strandboge
FYI, a 2.4.3 SRU is in flight (by amurray), but looking at
https://github.com/seccomp/libseccomp/pull/180 (the fix for the bug),
https://github.com/seccomp/libseccomp/issues/187 (2.4.3 backports), and
code inspection, the fix for the bug is not in 2.4.3 and will come in
2.5.

The security team is not currently working on this, but that could be
changed (that should be discussed outside of this bug).

** Bug watch added: github.com/seccomp/libseccomp/issues #187
   https://github.com/seccomp/libseccomp/issues/187

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

Title:
  seccomp_rule_add is very slow

Status in snapd:
  Triaged
Status in libseccomp package in Ubuntu:
  In Progress

Bug description:
  There is a known and patched issue with version 2.4 of libseccomp
  where certain operations have a large performance regression. This is
  causing some packages that use libseccomp such as container
  orchestration systems to occasionally time out or otherwise fail under
  certain workloads.

  Please consider porting the patch into the various Ubuntu versions
  that have version 2.4 of libseccomp and into the backports. The
  performance patch from version 2.5 (yet to be released) applies
  cleanly on top of the 2.4 branch of libseccomp.

  For more information, and for a copy of the patch (which can also be
  cherry picked from the upstream libseccomp repos) see the similar
  Debian issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913

To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1861177/+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-06-01 Thread Jamie Strandboge
FYI, those re-runs passed and the package is green in
https://people.canonical.com/~ubuntu-archive/pending-sru.html. When
ubuntu-sru goes through the queue, this will be published.

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

[Touch-packages] [Bug 1868720] Re: backport time64 syscalls whitelist

2020-05-28 Thread Jamie Strandboge
There is actually an SRU in progress for libseccomp:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1876055.

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

Title:
  backport time64 syscalls whitelist

Status in docker.io package in Ubuntu:
  New
Status in libseccomp package in Ubuntu:
  Fix Released
Status in docker.io source package in Bionic:
  New
Status in libseccomp source package in Bionic:
  Triaged
Status in docker.io source package in Disco:
  Won't Fix
Status in libseccomp source package in Disco:
  Won't Fix
Status in docker.io source package in Eoan:
  New
Status in libseccomp source package in Eoan:
  Triaged
Status in docker.io source package in Focal:
  New
Status in libseccomp source package in Focal:
  Fix Released

Bug description:
  A number of new *time64 syscalls are introduced in newer kernel series
  (>=5.1.x):

  403: clock_gettime64
  404: clock_settime64
  405: clock_adjtime64
  406: clock_getres_time64
  407: clock_nanosleep_time64
  408: timer_gettime64
  409: timer_settime64
  410: timerfd_gettime64
  411: timerfd_settime64
  412: utimensat_time64
  413: pselect6_time64
  414: ppoll_time64

  In particular utimensat_time64 is now used inside glibc>=2.31

  In turn ubuntu with has trouble running docker images of newer distros.
  This problem affects libseccomp<2.4.2, ie bionic (lts), and eoan, but not 
focal.

  See a similar report at Fedora:
  https://bugzilla.redhat.com/show_bug.cgi?id=1770154

  A solution could be to backport the related changes from 2.4.2
  similarly to what happened for the statx whitelisting
  (https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1755250).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1868720/+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-28 Thread Jamie Strandboge
The autopkgtest failures seem unrelated. I triggered reruns just now.

-- 
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 UTC 
2020 x86_64 x86_64 x86_64 GNU/Linux

  

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

2020-05-28 Thread Jamie Strandboge
@Marco, this issue is not yet fixed in Focal. Marking back to Fix
Committed.

** Changed in: apparmor (Ubuntu Focal)
   Status: Fix Released => 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 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 

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

2020-05-19 Thread Jamie Strandboge
@Sergio - assuming you are ok with my patch, do you still plan to follow
through on the SRU verification once it is accepted into focal-proposed?

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

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

2020-05-19 Thread Jamie Strandboge
@Sergio, I didn't see that you uploaded anything to the queue so to
expedite the SRU since there are a number of duplicates, I created a
smaller backport of the fix and uploaded it to focal-proposed just now:
http://launchpadlibrarian.net/480473812/apparmor_2.13.3-7ubuntu5_2.13.3-7ubuntu5.1.diff.gz

(I hope that is alright).

** Changed in: apparmor (Ubuntu Focal)
   Status: Confirmed => In Progress

-- 
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: 

[Touch-packages] [Bug 1721704] Re: Printer settings stuck on loading drivers database

2020-05-19 Thread Jamie Strandboge
@Till, the boot_id issue is being tracked here:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1872564

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

Title:
  Printer settings stuck on loading drivers database

Status in apparmor package in Ubuntu:
  New
Status in system-config-printer package in Ubuntu:
  Incomplete

Bug description:
  1) Description:   Ubuntu Artful Aardvark (development branch)
 Release:   17.10
  2) ubuntu-settings:
 Installed: 17.10.17
 Candidate: 17.10.17
  3) The printer configuration goes fine and I can print
  4) Printer settings stuck on loading drivers database and finally no drivers 
list available. Only 'cancel' button active.

  Note: I'm trying to configure a Brother HL-2030 connected to Network
  through a FritzBox 7940 router. The printer works fine both on Fedora
  and macOS X systems. I opened 'System Settings', then select 'Devices'
  > 'Printers' > 'Add a Printer'. I entered the router address and the
  window shows me correctly a 'JetDirect-Printer' on 192.168.178.1. I
  selected the printer and pressed the 'Add' button, a window 'Select
  Printer Driver' appears and stuck with 'Loading drivers database...'.
  After about 2 minutes, stopped loading and remains blank. No drivers
  selection is available and I can only push the 'Cancel' button.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1721704/+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 1878814] Re: apparmor stays active even when the service is disabled

2020-05-15 Thread Jamie Strandboge
I'm not familiar with mysql-workbench-community, but looking at the logs
I see:

May 14 17:44:33 owen-AOD255 kernel: [  181.312508] audit: type=1400
audit(1589474673.710:1024): apparmor="DENIED" operation="connect"
profile="snap.mysql-workbench-community.mysql-workbench-community"
name="/run/uuidd/request" pid=3579 comm="mysql-workbench"
requested_mask="w" denied_mask="w" fsuid=1000 ouid=0

This issue was fixed in a recent commit to snapd, but it hasn't reached
the stable channel yet (it should be in snapd 2.45). You can either:

* 'sudo snap install --devmode mysql-workbench-community' to work around the 
issue and put apparmor into complain mode
* 'sudo snap refresh snapd --edge' to pull in the edge build of snapd which has 
the fix

If choosing the former, when 'snap version' reports 2.45, you can
install the snap in strict mode (omit --devmode). If the latter, when
'snap info snapd' reports that 2.45 is in the stable channel, run 'sudo
snap refresh snapd --stable' to start tracking stable again.

This is not a bug in apparmor, but instead snapd. Triaging the bug as
such.

** Package changed: apparmor (Ubuntu) => snapd (Ubuntu)

** Changed in: snapd (Ubuntu)
   Importance: Undecided => Medium

** Changed in: snapd (Ubuntu)
   Status: New => In Progress

** Changed in: snapd (Ubuntu)
Milestone: None => focal-updates

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

Title:
  apparmor stays active even when the service is disabled

Status in snapd package in Ubuntu:
  In Progress

Bug description:
  Trying to access a fresh install of MySQL, what a complete pain that
  is!! I installed mysql-workbench-community from the app store.
  Attempts to access the database with user root were rebuffed by an
  AppArmor error about permissions.

  Running aa-status I could see the app in the enforce category, so I
  made many attempts to move it to complain, but this failed and I'll
  file a bug report about that as well.

  I decided to disable both the apparmor and ufw service.

  However, the AppArmor permissions error dialog continue to appear and
  it's not possible to access the database.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: apparmor 2.13.3-7ubuntu5
  ProcVersionSignature: Ubuntu 5.4.0-29.33-generic 5.4.30
  Uname: Linux 5.4.0-29-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Fri May 15 09:40:01 2020
  InstallationDate: Installed on 2020-03-10 (65 days ago)
  InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200306)
  ProcKernelCmdline: BOOT_IMAGE=/boot/vmlinuz-5.4.0-29-generic 
root=UUID=d73f3324-549c-4a63-b2bd-f813366411ac ro quiet splash vt.handoff=7
  SourcePackage: apparmor
  Syslog:
   May 15 09:38:16 owen-AOD255 dbus-daemon[1118]: [session uid=125 pid=1118] 
AppArmor D-Bus mediation is enabled
   May 15 09:39:00 owen-AOD255 dbus-daemon[1762]: [session uid=1000 pid=1762] 
AppArmor D-Bus mediation is enabled
   May 15 09:39:04 owen-AOD255 dbus-daemon[2353]: [session uid=125 pid=2353] 
AppArmor D-Bus mediation is enabled
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1878814/+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 1878862] Re: AppArmor - Cannot move snap packages from enforce to complain

2020-05-15 Thread Jamie Strandboge
snapd manages the security policies for snaps (and it will rewrite the
profiles at some point if you modify them yourself). You may install a
snap in devmode which puts apparmor in complain. Eg:

sudo snap install --devmode mysql-workbench-community

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

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

Title:
  AppArmor - Cannot move snap packages from enforce to complain

Status in apparmor package in Ubuntu:
  Invalid

Bug description:
  I installed mysql-workbench-community from the app store but it is
  unable to actually access the local database due to AppArmor
  intervention.

  All attempts to move the app in to complain results in error messages.

  ~# aa-status 
  apparmor module is loaded.
  10 profiles are loaded.
  10 profiles are in enforce mode.
  .
 snap.mysql-workbench-community.mysql-workbench-community
  .
  0 profiles are in complain mode.
  0 processes have profiles defined.
  0 processes are in enforce mode.
  0 processes are in complain mode.
  0 processes are unconfined but have a profile defined.

  ~# aa-complain /snap/bin/mysql-workbench-community
  Profile for /usr/bin/snap not found, skipping

  ~# aa-complain snap.mysql-workbench-community
  Can't find snap.mysql-workbench-community in the system path list. If the 
name of the application
  is correct, please run 'which snap.mysql-workbench-community' as a user with 
correct PATH
  environment set up in order to find the fully-qualified path and
  use the full path as parameter.

  ~# aa-complain snap.mysql-workbench-community.mysql-workbench-community
  Can't find snap.mysql-workbench-community.mysql-workbench-community in the 
system path list. If the name of the application
  is correct, please run 'which 
snap.mysql-workbench-community.mysql-workbench-community' as a user with 
correct PATH
  environment set up in order to find the fully-qualified path and
  use the full path as parameter.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: apparmor 2.13.3-7ubuntu5
  ProcVersionSignature: Ubuntu 5.4.0-29.33-generic 5.4.30
  Uname: Linux 5.4.0-29-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Fri May 15 09:47:56 2020
  InstallationDate: Installed on 2020-03-10 (65 days ago)
  InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200306)
  ProcEnviron:
   LANGUAGE=en_GB:en
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdline: BOOT_IMAGE=/boot/vmlinuz-5.4.0-29-generic 
root=UUID=d73f3324-549c-4a63-b2bd-f813366411ac ro quiet splash vt.handoff=7
  SourcePackage: apparmor
  Syslog:
   May 15 09:38:16 owen-AOD255 dbus-daemon[1118]: [session uid=125 pid=1118] 
AppArmor D-Bus mediation is enabled
   May 15 09:39:00 owen-AOD255 dbus-daemon[1762]: [session uid=1000 pid=1762] 
AppArmor D-Bus mediation is enabled
   May 15 09:39:04 owen-AOD255 dbus-daemon[2353]: [session uid=125 pid=2353] 
AppArmor D-Bus mediation is enabled
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1878862/+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 1870729] Re: DHCP Server regularly killed code=killed, status=6/ABRT

2020-05-14 Thread Jamie Strandboge
This bug is marked fixed release. As I suggested in comment #13, please
file a new bug. This will allow you to use apport to upload any crash
information/etc that will assist developers in fixing this.

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

Title:
  DHCP Server regularly killed code=killed, status=6/ABRT

Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in isc-dhcp source package in Focal:
  Fix Released

Bug description:
  On Ubuntu 20.04 The idc-dhcp- server version is
  isc-dhcp-server:
Installed: (none)
Candidate: 4.4.1-2.1ubuntu3
Version table:
   4.4.1-2.1ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages

  
  The DHCP server is being regularly killed, when searching google the  bug 
looks very similar to an older bug regarding accessing a lease file, that was 
fixed year ago. As a temporary fix in systemd I have enabled a restart every 
time the main process fails. The error got worse when i start to run a pair of 
dhcp servers syncing state between each other

  
  I regularly see the following in the syslog

  Apr  4 00:04:55 gw sh[1500]: ../../../../lib/isc/unix/socket.c:3361: 
INSIST(!sock->pending_send) failed, back trace
  Apr  4 00:04:55 gw sh[1500]: #0 0x7f36befeda4a in ??
  Apr  4 00:04:55 gw sh[1500]: #1 0x7f36befed980 in ??
  Apr  4 00:04:55 gw sh[1500]: #2 0x7f36bf0297e1 in ??
  Apr  4 00:04:55 gw sh[1500]: #3 0x7f36bedd0609 in ??
  Apr  4 00:04:55 gw sh[1500]: #4 0x7f36bef0c153 in ??
  Apr  4 00:04:55 gw systemd[1]: isc-dhcp-server.service: Main process exited, 
code=killed, status=6/ABRT
  Apr  4 00:04:55 gw systemd[1]: isc-dhcp-server.service: Failed with result 
'signal'.
  Apr  4 00:05:00 gw systemd[1]: isc-dhcp-server.service: Scheduled restart 
job, restart counter is at 3.
  Apr  4 00:05:00 gw systemd[1]: Stopped ISC DHCP IPv4 server.
  Apr  4 00:05:00 gw systemd[1]: Started ISC DHCP IPv4 server.
  Apr  4 00:05:00 gw kernel: [ 3508.161248] audit: type=1400 
audit(1585958700.678:46): apparmor="DENIED" operation="open" 
profile="/usr/sbin/dhcpd" name="/proc/2049/task/2068/comm" pid=2049 
comm="dhcpd" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
  Apr  4 00:05:00 gw dhcpd[2049]: Internet Systems Consortium DHCP Server 4.4.1
  Apr  4 00:05:00 gw sh[2049]: Internet Systems Consortium DHCP Server 4.4.1
  Apr  4 00:05:00 gw sh[2049]: Copyright 2004-2018 Internet Systems Consortium.
  Apr  4 00:05:00 gw sh[2049]: All rights reserved.
  Apr  4 00:05:00 gw sh[2049]: For info, please visit 
https://www.isc.org/software/dhcp/
  Apr  4 00:05:00 gw dhcpd[2049]: Copyright 2004-2018 Internet Systems 
Consortium.
  Apr  4 00:05:00 gw dhcpd[2049]: All rights reserved.
  Apr  4 00:05:00 gw dhcpd[2049]: For info, please visit 
https://www.isc.org/software/dhcp/
  Apr  4 00:05:00 gw kernel: [ 3508.161561] audit: type=1400 
audit(1585958700.678:47): apparmor="DENIED" operation="open" 
profile="/usr/sbin/dhcpd" name="/proc/2049/task/2069/comm" pid=2049 
comm="dhcpd" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
  Apr  4 00:05:00 gw kernel: [ 3508.161563] audit: type=1400 
audit(1585958700.682:48): apparmor="DENIED" operation="open" 
profile="/usr/sbin/dhcpd" name="/proc/2049/task/2070/comm" pid=2049 
comm="dhcpd" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
  Apr  4 00:05:00 gw dhcpd[2049]: Config file: /etc/dhcp/dhcpd.conf
  Apr  4 00:05:00 gw sh[2049]: Config file: /etc/dhcp/dhcpd.conf
  Apr  4 00:05:00 gw sh[2049]: Database file: /var/lib/dhcp/dhcpd.leases
  Apr  4 00:05:00 gw sh[2049]: PID file: /run/dhcp-server/dhcpd.pid
  Apr  4 00:05:00 gw dhcpd[2049]: Database file: /var/lib/dhcp/dhcpd.leases
  Apr  4 00:05:00 gw dhcpd[2049]: PID file: /run/dhcp-server/dhcpd.pid
  Apr  4 00:05:00 gw dhcpd[2049]: Wrote 0 deleted host decls to leases file.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1870729/+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 1877633] Re: libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the getrlimit syscall on arm64

2020-05-13 Thread Jamie Strandboge
** Changed in: libseccomp (Ubuntu Focal)
   Status: Confirmed => In Progress

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

Title:
  libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the
  getrlimit syscall on arm64

Status in libseccomp package in Ubuntu:
  Fix Released
Status in libseccomp source package in Focal:
  In Progress
Status in libseccomp source package in Groovy:
  Fix Released

Bug description:
  This was reported via the snapcraft forum[1]:

  On bionic amd64, libseccomp 2.4.1-0ubuntu0.18.04.2

  $ lsb_release -d
  Description:  Ubuntu 18.04.4 LTS
  $ scmp_sys_resolver -a aarch64 163
  getrlimit
  $ scmp_sys_resolver -a aarch64 getrlimit
  163

  focal amd64, libseccomp 2.4.3-1ubuntu1 -- *__BROKEN__*

  $ lsb_release -d
  Description:  Ubuntu 20.04 LTS
  $ scmp_sys_resolver -a aarch64 163
  UNKNOWN
  $ scmp_sys_resolver -a aarch64 getrlimit
  -10180

  [1]https://forum.snapcraft.io/t/getrlimit-blocked-by-seccomp-on-focal-
  arm64/17237/8

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1877633/+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 1877633] Re: libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the getrlimit syscall on arm64

2020-05-12 Thread Jamie Strandboge
Thanks for the debdiff Alex. Uploaded to groovy-proposed.

** Changed in: libseccomp (Ubuntu Groovy)
   Status: Confirmed => Fix Committed

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

Title:
  libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the
  getrlimit syscall on arm64

Status in libseccomp package in Ubuntu:
  Fix Committed
Status in libseccomp source package in Focal:
  Confirmed
Status in libseccomp source package in Groovy:
  Fix Committed

Bug description:
  This was reported via the snapcraft forum[1]:

  On bionic amd64, libseccomp 2.4.1-0ubuntu0.18.04.2

  $ lsb_release -d
  Description:  Ubuntu 18.04.4 LTS
  $ scmp_sys_resolver -a aarch64 163
  getrlimit
  $ scmp_sys_resolver -a aarch64 getrlimit
  163

  focal amd64, libseccomp 2.4.3-1ubuntu1 -- *__BROKEN__*

  $ lsb_release -d
  Description:  Ubuntu 20.04 LTS
  $ scmp_sys_resolver -a aarch64 163
  UNKNOWN
  $ scmp_sys_resolver -a aarch64 getrlimit
  -10180

  [1]https://forum.snapcraft.io/t/getrlimit-blocked-by-seccomp-on-focal-
  arm64/17237/8

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1877633/+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 1876065] Re: After unplug headphones and plug them again no sound can be heard

2020-05-12 Thread Jamie Strandboge
Rather than superseding 1:13.99.1-1ubuntu4 in groovy-proposed, I instead
based the changes in 1:13.99.1-1ubuntu5 on top of 1:13.99.1-1ubuntu4 to
address the CVE that was fixed in https://usn.ubuntu.com/4355-1/.

** Also affects: pulseaudio (Ubuntu Groovy)
   Importance: High
 Assignee: Kai-Heng Feng (kaihengfeng)
   Status: Fix Committed

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

Title:
  After unplug headphones and plug them again no sound can be heard

Status in pulseaudio package in Ubuntu:
  Fix Committed
Status in pulseaudio source package in Focal:
  Fix Committed
Status in pulseaudio source package in Groovy:
  Fix Committed

Bug description:
  * Impact
  Sound isn't automatically redirected to headphones when those are connected 
to a jack interface

  * Test case
  Disconnect the headsets
  Start your webbrowser/music player/video player and play some sound
  Connect the headsets to the jack interface

  -> the sound should be directly redirected to the plugged headsets

  * Regression potential
  Check that audio routing when connecting/disconnecting devices to the hack 
entry is working correctly

  

  After startup with headset plugged in they play sound nicely - no
  issue. When they are unplugged, the sound is switched to the speaker
  (laptop) - all good. However, when I plug the headset back there is no
  sound. I see the app on pavucontrol, the volume is fine - everything
  looks fine except there is no sound. I dumped output of "pactl list"
  command on startup (headset plugged), after unplugging the headset,
  and when it is plugged back. From the comparison of these outputs, it
  looks like the source has got muted after the headset is plugged.

  Source #1
   State: RUNNING
   Name: alsa_input.pci-_00_1f.3.analog-stereo
   Description: Built-in Audio Analog Stereo
   Driver: module-alsa-card.c
   Sample Specification: s16le 2ch 44100Hz
   Channel Map: front-left,front-right
   Owner Module: 7
   Mute: yes

  Attached three outputs:
  headset-in.txt - after startup with headset plugged - all fine.
  headset-out.txt - after unplugged headset - sound through the speaker - all 
fine.
  headset-back.txt - after plugged headset back - no sound.

  Any help greatly appreciated.

  Regards,
  Roman

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1876065/+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 1877102] Re: snap policy module can be unloaded, circumventing audio recording restrictions for snaps

2020-05-12 Thread Jamie Strandboge
Uploaded
https://launchpad.net/ubuntu/+source/pulseaudio/1:13.99.1-1ubuntu5 to
groovy based on 1:13.99.1-1ubuntu4 from groovy-proposed.

** Changed in: pulseaudio (Ubuntu Groovy)
   Status: In Progress => Fix Committed

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

Title:
  snap policy module can be unloaded, circumventing audio recording
  restrictions for snaps

Status in pulseaudio package in Ubuntu:
  Fix Committed
Status in pulseaudio source package in Xenial:
  Fix Released
Status in pulseaudio source package in Bionic:
  Fix Released
Status in pulseaudio source package in Eoan:
  Fix Released
Status in pulseaudio source package in Focal:
  Fix Released
Status in pulseaudio source package in Groovy:
  Fix Committed

Bug description:
  This collates information about a security vulnerability discussed in
  email.  It has been assigned CVE-2020-11931.

  Ubuntu's PulseAudio package is shipped with a custom "module-snap-
  policy" module intended to restrict snap confined clients from
  recording audio unless they have the "audio-record" plug connected.
  However, it does not restrict access to the "PA_COMMAND_UNLOAD_MODULE"
  command.

  This allows a snap that has only plugged "audio-playback" to request
  that PulseAudio unload the security policy module, which in turn makes
  it possible to record audio.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1877102/+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 1877102] Re: snap policy module can be unloaded, circumventing audio recording restrictions for snaps

2020-05-12 Thread Jamie Strandboge
I'll apply the focal patch to what is in groovy-proposed.

** Changed in: pulseaudio (Ubuntu Groovy)
 Assignee: (unassigned) => Jamie Strandboge (jdstrand)

** Changed in: pulseaudio (Ubuntu Groovy)
   Status: Triaged => In Progress

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

Title:
  snap policy module can be unloaded, circumventing audio recording
  restrictions for snaps

Status in pulseaudio package in Ubuntu:
  In Progress
Status in pulseaudio source package in Xenial:
  Fix Released
Status in pulseaudio source package in Bionic:
  Fix Released
Status in pulseaudio source package in Eoan:
  Fix Released
Status in pulseaudio source package in Focal:
  Fix Released
Status in pulseaudio source package in Groovy:
  In Progress

Bug description:
  This collates information about a security vulnerability discussed in
  email.  It has been assigned CVE-2020-11931.

  Ubuntu's PulseAudio package is shipped with a custom "module-snap-
  policy" module intended to restrict snap confined clients from
  recording audio unless they have the "audio-record" plug connected.
  However, it does not restrict access to the "PA_COMMAND_UNLOAD_MODULE"
  command.

  This allows a snap that has only plugged "audio-playback" to request
  that PulseAudio unload the security policy module, which in turn makes
  it possible to record audio.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1877102/+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 1869819] Re: [SRU] System can't detect external headset in the codec of Conexant

2020-05-12 Thread Jamie Strandboge
FYI, the upload to bionic-proposed was superseded by
https://usn.ubuntu.com/4355-1/. Please rebase your changes on that and
reupload.

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

Title:
  [SRU] System can't detect external headset in the codec of Conexant

Status in OEM Priority Project:
  Confirmed
Status in OEM Priority Project bionic series:
  New
Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Bionic:
  In Progress
Status in pulseaudio source package in Focal:
  Fix Released

Bug description:
  [Impact]
  In some hp's devices, there are two audio jacks(one headset and one 
headphone) in the audio interface which is using the codec of Conexant, and 
apparently it's not working, the system can't detect the headset in current 
codec.

  [Test Case]
  1. Insert 4 rings(3 stripes) headset into front audio port (headset icon)
  2. Check System Setting->Sound->Output

  [Expected result]
  Can detect external headset

  [Actual result]
  Only shows internal speaker.
  External headset microphone was detected.
  Another front audio port (earphone icon) works fine.

  [Regression Potential]
  Low.

  [Failure rate]
  100%

  [Additional information]
  system-product-name: HP EliteDesk 800 G5 SFF
  CPU: Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz (8x)
  GPU: 00:02.0 VGA compatible controller [0300]: Intel Corporation Device 
[8086:3e98] (rev 02)
  OS-version: 18.04
  kernel-version: 4.15.0-1065-oem
  pulseaudio-version: 1:11.1-1ubuntu7.2

  Upstream issue:
  https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/272

  Ubuntu-Focal-Source:
  
https://code.launchpad.net/~hugh712/ubuntu/+source/pulseaudio/+git/pulseaudio/+ref/focal-1869819

  PPA: https://launchpad.net/~hugh712/+archive/ubuntu/sru-1869819

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1869819/+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 1876065] Re: After unplug headphones and plug them again no sound can be heard

2020-05-12 Thread Jamie Strandboge
FYI, the upload to focal-proposed was superseded by
https://usn.ubuntu.com/4355-1/. Please rebase your changes on that and
reupload.

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

Title:
  After unplug headphones and plug them again no sound can be heard

Status in pulseaudio package in Ubuntu:
  Fix Committed
Status in pulseaudio source package in Focal:
  Fix Committed

Bug description:
  * Impact
  Sound isn't automatically redirected to headphones when those are connected 
to a jack interface

  * Test case
  Disconnect the headsets
  Start your webbrowser/music player/video player and play some sound
  Connect the headsets to the jack interface

  -> the sound should be directly redirected to the plugged headsets

  * Regression potential
  Check that audio routing when connecting/disconnecting devices to the hack 
entry is working correctly

  

  After startup with headset plugged in they play sound nicely - no
  issue. When they are unplugged, the sound is switched to the speaker
  (laptop) - all good. However, when I plug the headset back there is no
  sound. I see the app on pavucontrol, the volume is fine - everything
  looks fine except there is no sound. I dumped output of "pactl list"
  command on startup (headset plugged), after unplugging the headset,
  and when it is plugged back. From the comparison of these outputs, it
  looks like the source has got muted after the headset is plugged.

  Source #1
   State: RUNNING
   Name: alsa_input.pci-_00_1f.3.analog-stereo
   Description: Built-in Audio Analog Stereo
   Driver: module-alsa-card.c
   Sample Specification: s16le 2ch 44100Hz
   Channel Map: front-left,front-right
   Owner Module: 7
   Mute: yes

  Attached three outputs:
  headset-in.txt - after startup with headset plugged - all fine.
  headset-out.txt - after unplugged headset - sound through the speaker - all 
fine.
  headset-back.txt - after plugged headset back - no sound.

  Any help greatly appreciated.

  Regards,
  Roman

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1876065/+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 1877102] Re: snap policy module can be unloaded, circumventing audio recording restrictions for snaps

2020-05-12 Thread Jamie Strandboge
** Changed in: pulseaudio (Ubuntu Groovy)
   Importance: High => Medium

** Changed in: pulseaudio (Ubuntu Focal)
   Importance: Undecided => Medium

** Changed in: pulseaudio (Ubuntu Eoan)
   Importance: Undecided => Medium

** Changed in: pulseaudio (Ubuntu Bionic)
   Importance: Undecided => Medium

** Changed in: pulseaudio (Ubuntu Xenial)
   Importance: Undecided => Medium

** 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 pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1877102

Title:
  snap policy module can be unloaded, circumventing audio recording
  restrictions for snaps

Status in pulseaudio package in Ubuntu:
  Triaged
Status in pulseaudio source package in Xenial:
  Fix Released
Status in pulseaudio source package in Bionic:
  Fix Released
Status in pulseaudio source package in Eoan:
  Fix Released
Status in pulseaudio source package in Focal:
  Fix Released
Status in pulseaudio source package in Groovy:
  Triaged

Bug description:
  This collates information about a security vulnerability discussed in
  email.  It has been assigned CVE-2020-11931.

  Ubuntu's PulseAudio package is shipped with a custom "module-snap-
  policy" module intended to restrict snap confined clients from
  recording audio unless they have the "audio-record" plug connected.
  However, it does not restrict access to the "PA_COMMAND_UNLOAD_MODULE"
  command.

  This allows a snap that has only plugged "audio-playback" to request
  that PulseAudio unload the security policy module, which in turn makes
  it possible to record audio.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1877102/+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 1878175] Re: Abstraction needs access to @{PROC}/sys/kernel/random/boot_id

2020-05-12 Thread Jamie Strandboge
*** This bug is a duplicate of bug 1872564 ***
https://bugs.launchpad.net/bugs/1872564

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

** This bug has been marked a duplicate of bug 1872564
   /proc/sys/kernel/random/boot_id rule missing from abstractions/nameservice

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

Title:
  Abstraction needs access to @{PROC}/sys/kernel/random/boot_id

Status in apparmor package in Ubuntu:
  Confirmed

Bug description:
  This concerns apparmor 2.13.3-7ubuntu5 in Ubuntu focal.

  I have AppArmor actively enforcing policy on my system. In
  /var/log/syslog, I see a number of the following two sorts of
  messages:

  May 12 04:44:21 image-ubuntu64 kernel: [   26.667094] audit: type=1400
  audit(1589273061.296:63): apparmor="DENIED" operation="open"
  profile="nscd" name="/proc/sys/kernel/random/boot_id" pid=655
  comm="nscd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

  May 12 04:44:26 image-ubuntu64 kernel: [   32.107018] audit: type=1400
  audit(1589273066.730:99): apparmor="DENIED" operation="open"
  profile="/usr/sbin/nslcd" name="/proc/sys/kernel/random/boot_id"
  pid=1004 comm="nslcd" requested_mask="r" denied_mask="r" fsuid=0
  ouid=0

  The following line is needed in an abstraction somewhere:

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

  I've added it locally to /etc/apparmor.d/abstractions/nameservice, and
  that took care of the above errors for me. AppArmor upstream has added
  it to abstractions/nss-systemd, but this file does not exist in
  Ubuntu's apparmor package.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1878175/+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 1873764] Re: CUPS Apparmor Error opening /proc/sys/kernel/random/boot_id

2020-05-11 Thread Jamie Strandboge
*** This bug is a duplicate of bug 1872564 ***
https://bugs.launchpad.net/bugs/1872564

This is a dupe of
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1872564 which,
AIUI, the server team will be performing an SRU for.

** This bug has been marked a duplicate of bug 1872564
   /proc/sys/kernel/random/boot_id rule missing from abstractions/nameservice

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

Title:
  CUPS Apparmor Error opening /proc/sys/kernel/random/boot_id

Status in cups package in Ubuntu:
  Confirmed

Bug description:
  I noted the following messages on a just installed Ubuntu Focal:

  $ dmesg | grep cups
  [ 1769.505132] audit: type=1400 audit(1587372138.575:3011): apparmor="DENIED" 
operation="capable" profile="/usr/sbin/cups-browsed" pid=15230 
comm="cups-browsed" capability=23  capname="sys_nice"
  [ 1776.623181] audit: type=1400 audit(1587372145.693:3012): apparmor="DENIED" 
operation="capable" profile="/usr/sbin/cups-browsed" pid=15510 
comm="cups-browsed" capability=23  capname="sys_nice"
  [ 2040.426033] audit: type=1400 audit(1587372409.494:3013): apparmor="DENIED" 
operation="open" profile="/usr/sbin/cupsd" 
name="/proc/sys/kernel/random/boot_id" pid=15508 comm="cupsd" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
  [ 2040.426044] audit: type=1400 audit(1587372409.494:3014): apparmor="DENIED" 
operation="open" profile="/usr/sbin/cupsd" 
name="/proc/sys/kernel/random/boot_id" pid=15508 comm="cupsd" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
  [ 2040.426074] audit: type=1400 audit(1587372409.494:3015): apparmor="DENIED" 
operation="open" profile="/usr/sbin/cupsd" 
name="/proc/sys/kernel/random/boot_id" pid=15508 comm="cupsd" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
  [ 2040.426092] audit: type=1400 audit(1587372409.494:3016): apparmor="DENIED" 
operation="open" profile="/usr/sbin/cupsd" 
name="/proc/sys/kernel/random/boot_id" pid=15508 comm="cupsd" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
  [ 2040.426106] audit: type=1400 audit(1587372409.494:3017): apparmor="DENIED" 
operation="open" profile="/usr/sbin/cupsd" 
name="/proc/sys/kernel/random/boot_id" pid=15508 comm="cupsd" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
  [ 2041.404914] audit: type=1400 audit(1587372410.473:3018): apparmor="DENIED" 
operation="open" profile="/usr/sbin/cupsd" 
name="/proc/sys/kernel/random/boot_id" pid=15508 comm="cupsd" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
  [ 2041.404920] audit: type=1400 audit(1587372410.473:3019): apparmor="DENIED" 
operation="open" profile="/usr/sbin/cupsd" 
name="/proc/sys/kernel/random/boot_id" pid=15508 comm="cupsd" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
  [ 2041.404926] audit: type=1400 audit(1587372410.473:3020): apparmor="DENIED" 
operation="open" profile="/usr/sbin/cupsd" 
name="/proc/sys/kernel/random/boot_id" pid=15508 comm="cupsd" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
  [ 2041.404953] audit: type=1400 audit(1587372410.473:3021): apparmor="DENIED" 
operation="open" profile="/usr/sbin/cupsd" 
name="/proc/sys/kernel/random/boot_id" pid=15508 comm="cupsd" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
  [ 2041.404963] audit: type=1400 audit(1587372410.473:3022): apparmor="DENIED" 
operation="open" profile="/usr/sbin/cupsd" 
name="/proc/sys/kernel/random/boot_id" pid=15508 comm="cupsd" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
  [ 2071.925327] audit: type=1400 audit(1587372440.994:3028): apparmor="DENIED" 
operation="open" profile="/usr/sbin/cupsd" 
name="/proc/sys/kernel/random/boot_id" pid=15508 comm="cupsd" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
  [ 2071.925330] audit: type=1400 audit(1587372440.994:3029): apparmor="DENIED" 
operation="open" profile="/usr/sbin/cupsd" 
name="/proc/sys/kernel/random/boot_id" pid=15508 comm="cupsd" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
  [ 2071.925337] audit: type=1400 audit(1587372440.994:3030): apparmor="DENIED" 
operation="open" profile="/usr/sbin/cupsd" 
name="/proc/sys/kernel/random/boot_id" pid=15508 comm="cupsd" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
  [ 2071.925382] audit: type=1400 audit(1587372440.994:3031): apparmor="DENIED" 
operation="open" profile="/usr/sbin/cupsd" 
name="/proc/sys/kernel/random/boot_id" pid=15508 comm="cupsd" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
  [ 2071.925391] audit: type=1400 audit(1587372440.994:3032): apparmor="DENIED" 
operation="open" profile="/usr/sbin/cupsd" 
name="/proc/sys/kernel/random/boot_id" pid=15508 comm="cupsd" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0

  
  It happened after installing Brother DCPL3550CDW Linux drivers.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: cups-daemon 2.3.1-9ubuntu1
  ProcVersionSignature: Ubuntu 5.4.0-25.29-lowlatency 5.4.30
  Uname: Linux 5.4.0-25-lowlatency x86_64

[Touch-packages] [Bug 1877633] Re: libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the getrlimit syscall on arm64

2020-05-08 Thread Jamie Strandboge
** Description changed:

- This was reported via the snapcraft forum:
+ This was reported via the snapcraft forum[1]:
  
  On bionic amd64, libseccomp 2.4.1-0ubuntu0.18.04.2
  
  $ lsb_release -d
  Description:  Ubuntu 18.04.4 LTS
  $ scmp_sys_resolver -a aarch64 163
  getrlimit
  $ scmp_sys_resolver -a aarch64 getrlimit
  163
  
  focal amd64, libseccomp 2.4.3-1ubuntu1 -- *__BROKEN__*
  
  $ lsb_release -d
  Description:  Ubuntu 20.04 LTS
  $ scmp_sys_resolver -a aarch64 163
  UNKNOWN
  $ scmp_sys_resolver -a aarch64 getrlimit
  -10180
+ 
+ [1]https://forum.snapcraft.io/t/getrlimit-blocked-by-seccomp-on-focal-
+ arm64/17237/8

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

Title:
  libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the
  getrlimit syscall on arm64

Status in libseccomp package in Ubuntu:
  Confirmed
Status in libseccomp source package in Focal:
  Confirmed
Status in libseccomp source package in Groovy:
  Confirmed

Bug description:
  This was reported via the snapcraft forum[1]:

  On bionic amd64, libseccomp 2.4.1-0ubuntu0.18.04.2

  $ lsb_release -d
  Description:  Ubuntu 18.04.4 LTS
  $ scmp_sys_resolver -a aarch64 163
  getrlimit
  $ scmp_sys_resolver -a aarch64 getrlimit
  163

  focal amd64, libseccomp 2.4.3-1ubuntu1 -- *__BROKEN__*

  $ lsb_release -d
  Description:  Ubuntu 20.04 LTS
  $ scmp_sys_resolver -a aarch64 163
  UNKNOWN
  $ scmp_sys_resolver -a aarch64 getrlimit
  -10180

  [1]https://forum.snapcraft.io/t/getrlimit-blocked-by-seccomp-on-focal-
  arm64/17237/8

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1877633/+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 1877633] [NEW] libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the getrlimit syscall on arm64

2020-05-08 Thread Jamie Strandboge
Public bug reported:

This was reported via the snapcraft forum:

On bionic amd64, libseccomp 2.4.1-0ubuntu0.18.04.2

$ lsb_release -d
Description:Ubuntu 18.04.4 LTS
$ scmp_sys_resolver -a aarch64 163
getrlimit
$ scmp_sys_resolver -a aarch64 getrlimit
163

focal amd64, libseccomp 2.4.3-1ubuntu1 -- *__BROKEN__*

$ lsb_release -d
Description:Ubuntu 20.04 LTS
$ scmp_sys_resolver -a aarch64 163
UNKNOWN
$ scmp_sys_resolver -a aarch64 getrlimit
-10180

** Affects: libseccomp (Ubuntu)
 Importance: High
 Assignee: Alex Murray (alexmurray)
 Status: Confirmed

** Affects: libseccomp (Ubuntu Focal)
 Importance: High
 Assignee: Alex Murray (alexmurray)
 Status: Confirmed

** Affects: libseccomp (Ubuntu Groovy)
 Importance: High
 Assignee: Alex Murray (alexmurray)
 Status: Confirmed

** Also affects: libseccomp (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Also affects: libseccomp (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Changed in: libseccomp (Ubuntu Groovy)
   Status: New => Confirmed

** Changed in: libseccomp (Ubuntu Focal)
   Status: New => Confirmed

** Changed in: libseccomp (Ubuntu Groovy)
   Importance: Undecided => High

** Changed in: libseccomp (Ubuntu Focal)
   Importance: Undecided => High

** Changed in: libseccomp (Ubuntu Groovy)
 Assignee: (unassigned) => Alex Murray (alexmurray)

** Changed in: libseccomp (Ubuntu Focal)
 Assignee: (unassigned) => Alex Murray (alexmurray)

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

Title:
  libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the
  getrlimit syscall on arm64

Status in libseccomp package in Ubuntu:
  Confirmed
Status in libseccomp source package in Focal:
  Confirmed
Status in libseccomp source package in Groovy:
  Confirmed

Bug description:
  This was reported via the snapcraft forum:

  On bionic amd64, libseccomp 2.4.1-0ubuntu0.18.04.2

  $ lsb_release -d
  Description:  Ubuntu 18.04.4 LTS
  $ scmp_sys_resolver -a aarch64 163
  getrlimit
  $ scmp_sys_resolver -a aarch64 getrlimit
  163

  focal amd64, libseccomp 2.4.3-1ubuntu1 -- *__BROKEN__*

  $ lsb_release -d
  Description:  Ubuntu 20.04 LTS
  $ scmp_sys_resolver -a aarch64 163
  UNKNOWN
  $ scmp_sys_resolver -a aarch64 getrlimit
  -10180

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1877633/+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 1869819] Re: [SRU] System can't detect external headset in the codec of Conexant

2020-05-06 Thread Jamie Strandboge
FYI, there is a pending update that will go out either tomorrow or early
next week. Please base your next upload on this update.

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

Title:
  [SRU] System can't detect external headset in the codec of Conexant

Status in OEM Priority Project:
  Confirmed
Status in OEM Priority Project bionic series:
  New
Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Bionic:
  In Progress
Status in pulseaudio source package in Focal:
  Fix Released

Bug description:
  [Impact]
  In some hp's devices, there are two audio jacks(one headset and one 
headphone) in the audio interface which is using the codec of Conexant, and 
apparently it's not working, the system can't detect the headset in current 
codec.

  [Test Case]
  1. Insert 4 rings(3 stripes) headset into front audio port (headset icon)
  2. Check System Setting->Sound->Output

  [Expected result]
  Can detect external headset

  [Actual result]
  Only shows internal speaker.
  External headset microphone was detected.
  Another front audio port (earphone icon) works fine.

  [Regression Potential]
  Low.

  [Failure rate]
  100%

  [Additional information]
  system-product-name: HP EliteDesk 800 G5 SFF
  CPU: Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz (8x)
  GPU: 00:02.0 VGA compatible controller [0300]: Intel Corporation Device 
[8086:3e98] (rev 02)
  OS-version: 18.04
  kernel-version: 4.15.0-1065-oem
  pulseaudio-version: 1:11.1-1ubuntu7.2

  Upstream issue:
  https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/272

  Ubuntu-Focal-Source:
  
https://code.launchpad.net/~hugh712/ubuntu/+source/pulseaudio/+git/pulseaudio/+ref/focal-1869819

  PPA: https://launchpad.net/~hugh712/+archive/ubuntu/sru-1869819

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1869819/+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 1781428] Re: please enable snap mediation support

2020-04-17 Thread Jamie Strandboge
I confirmed that https://people.canonical.com/~ubuntu-archive/proposed-
migration/xenial/update_excuses.html shows no autopkgtest regression for
xenial.

I also ran through the TEST CASE for this bug and xenial passed. Marking
verification-done-xenial

** Tags removed: verification-failed-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 pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1781428

Title:
  please enable snap mediation support

Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Xenial:
  Fix Committed
Status in pulseaudio source package in Bionic:
  Fix Committed

Bug description:
  [Impact]
  Ubuntu 16.10 added rudimentary snap support to disable audio recording if the 
connecting process was a snap. By Ubuntu 18.04, something changed in the build 
resulting in 'Enable Snappy support: no' with audio recording no longer being 
mediated by pulseaudio (access to the pulseaudio socket continued to be 
mediated by snapd's apparmor policy). This resulted in any application with the 
pulseaudio interface connected to be able to also record. Ubuntu 16.04 never 
had mediation patches and always allowed recording when the pulseaudio 
interface was connected.

  To correct this situation but not regress existing behavior, Ubuntu
  19.04's pulseaudio was updated patch to allow playback to all
  connected clients (snaps or not), record by classic snaps (see bug
  1787324) and record by strict mode snaps if either the pulseaudio or
  new-in-snapd-2.41 audio-record interfaces were connected. With this
  change, snapd is in a position to migrate snaps to the new audio-
  playback and audio-record interfaces and properly mediate audio
  recording (see https://forum.snapcraft.io/t/upcoming-pulseaudio-
  interface-deprecation/13418).

  The patch to pulseaudio consists of adding a module, enabling it in
  default.pa and then when it is enabled, pulseaudio when faced with a
  record operation will, when the connecting process is a snap (ie, its
  security label (ie, apparmor label) starts with 'snap.'), query snapd
  via its control socket to ask if the snap is classic and if not,
  whether the pulseaudio or audio-record interfaces are connected.
  Adjusting pulseaudio in the manner does not require coordination with
  any release of snapd. It does need a newer version of snapd-glib,
  which was recently updated to 1.49 in the last SRU.

  [Test Case]

  IMPORTANT: if updating pulseaudio while the session is running, either
  need to reboot for the test or kill pulseaudio so it can restart with
  the new snap policy

  For unconfined applications:
  $ paplay /usr/share/sounds/alsa/Noise.wav && echo "yes"
  yes

  $ rm -f /tmp/out.wav ; parecord /tmp/out.wav && echo "yes"  # ctrl-c to stop 
recording
  ^Cyes

  $ paplay /tmp/out.wav && echo "yes"
  yes

  For confined, non-snap applications:
  $ sudo apt-get install evince

  $ aa-exec -p /usr/bin/evince -- paplay
  /usr/share/sounds/alsa/Noise.wav && echo yes

  $ rm -f /tmp/out.wav ; aa-exec -p /usr/bin/evince -- parecord /tmp/out.wav && 
echo "yes"  # ctrl-c to stop recording
  ^Cyes

  $ aa-exec -p /usr/bin/evince -- paplay /tmp/out.wav && echo "yes"
  yes

  For classic snaps:
  $ sudo snap install test-snapd-classic-confinement --classic

  $ snap run --shell test-snapd-classic-confinement

  $ cat /proc/self/attr/current   # verify we are classic confined
  snap.test-snapd-classic-confinement.test-snapd-classic-confinement (complain)

  $ paplay /usr/share/sounds/alsa/Noise.wav && echo "yes"
  yes

  $ rm -f /tmp/out.wav ; parecord /tmp/out.wav && echo "yes"  # ctrl-c to stop 
recording
  ^Cyes

  $ paplay /tmp/out.wav && echo "yes"
  yes

  $ exit # out of snap run --shell

  For strict snaps with pulseaudio:
  $ sudo snap install test-snapd-pulseaudio --edge
  $ sudo snap connect test-snapd-pulseaudio:pulseaudio

  $ snap connections test-snapd-pulseaudio
  Interface   Plug  Slot Notes
  pulseaudio  test-snapd-pulseaudio:pulseaudio  :pulseaudio  -

  $ test-snapd-pulseaudio.play --help  # ensure SNAP dirs are created
  ...

  $ sudo cp /usr/share/sounds/alsa/Noise.wav /var/snap/test-snapd-
  pulseaudio/common/

  $ test-snapd-pulseaudio.play /var/snap/test-snapd-pulseaudio/common/Noise.wav 
&& echo yes
  xcb_connection_has_error() returned true
  yes

  (note, the xcb_connection_has_error() message is due to the x11
  interface not being connected which is unrelated to mediation. x11 is
  left out to ensure that just audio-playback/audio-record are tested)

  $ test-snapd-pulseaudio.record /tmp/out.wav && echo yes # should pass
  ...
  ^Cyes

  $ test-snapd-pulseaudio.play /tmp/out.wav && echo yes
  ...
  yes

  For strict snaps with audio-playback/audio-record:
  $ sudo snap refresh core --candidate # make sure have 2.41. 'install' on 16.04
  $ sudo snap 

[Touch-packages] [Bug 1781428] Re: please enable snap mediation support

2020-04-17 Thread Jamie Strandboge
I confirmed that https://people.canonical.com/~ubuntu-archive/proposed-
migration/bionic/update_excuses.html shows no autopkgtest regression for
bionic.

I also ran through the TEST CASE for this bug and bionic passed. Marking
verification-done-bionic.


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

** Tags added: verification-done

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

Title:
  please enable snap mediation support

Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Xenial:
  Fix Committed
Status in pulseaudio source package in Bionic:
  Fix Committed

Bug description:
  [Impact]
  Ubuntu 16.10 added rudimentary snap support to disable audio recording if the 
connecting process was a snap. By Ubuntu 18.04, something changed in the build 
resulting in 'Enable Snappy support: no' with audio recording no longer being 
mediated by pulseaudio (access to the pulseaudio socket continued to be 
mediated by snapd's apparmor policy). This resulted in any application with the 
pulseaudio interface connected to be able to also record. Ubuntu 16.04 never 
had mediation patches and always allowed recording when the pulseaudio 
interface was connected.

  To correct this situation but not regress existing behavior, Ubuntu
  19.04's pulseaudio was updated patch to allow playback to all
  connected clients (snaps or not), record by classic snaps (see bug
  1787324) and record by strict mode snaps if either the pulseaudio or
  new-in-snapd-2.41 audio-record interfaces were connected. With this
  change, snapd is in a position to migrate snaps to the new audio-
  playback and audio-record interfaces and properly mediate audio
  recording (see https://forum.snapcraft.io/t/upcoming-pulseaudio-
  interface-deprecation/13418).

  The patch to pulseaudio consists of adding a module, enabling it in
  default.pa and then when it is enabled, pulseaudio when faced with a
  record operation will, when the connecting process is a snap (ie, its
  security label (ie, apparmor label) starts with 'snap.'), query snapd
  via its control socket to ask if the snap is classic and if not,
  whether the pulseaudio or audio-record interfaces are connected.
  Adjusting pulseaudio in the manner does not require coordination with
  any release of snapd. It does need a newer version of snapd-glib,
  which was recently updated to 1.49 in the last SRU.

  [Test Case]

  IMPORTANT: if updating pulseaudio while the session is running, either
  need to reboot for the test or kill pulseaudio so it can restart with
  the new snap policy

  For unconfined applications:
  $ paplay /usr/share/sounds/alsa/Noise.wav && echo "yes"
  yes

  $ rm -f /tmp/out.wav ; parecord /tmp/out.wav && echo "yes"  # ctrl-c to stop 
recording
  ^Cyes

  $ paplay /tmp/out.wav && echo "yes"
  yes

  For confined, non-snap applications:
  $ sudo apt-get install evince

  $ aa-exec -p /usr/bin/evince -- paplay
  /usr/share/sounds/alsa/Noise.wav && echo yes

  $ rm -f /tmp/out.wav ; aa-exec -p /usr/bin/evince -- parecord /tmp/out.wav && 
echo "yes"  # ctrl-c to stop recording
  ^Cyes

  $ aa-exec -p /usr/bin/evince -- paplay /tmp/out.wav && echo "yes"
  yes

  For classic snaps:
  $ sudo snap install test-snapd-classic-confinement --classic

  $ snap run --shell test-snapd-classic-confinement

  $ cat /proc/self/attr/current   # verify we are classic confined
  snap.test-snapd-classic-confinement.test-snapd-classic-confinement (complain)

  $ paplay /usr/share/sounds/alsa/Noise.wav && echo "yes"
  yes

  $ rm -f /tmp/out.wav ; parecord /tmp/out.wav && echo "yes"  # ctrl-c to stop 
recording
  ^Cyes

  $ paplay /tmp/out.wav && echo "yes"
  yes

  $ exit # out of snap run --shell

  For strict snaps with pulseaudio:
  $ sudo snap install test-snapd-pulseaudio --edge
  $ sudo snap connect test-snapd-pulseaudio:pulseaudio

  $ snap connections test-snapd-pulseaudio
  Interface   Plug  Slot Notes
  pulseaudio  test-snapd-pulseaudio:pulseaudio  :pulseaudio  -

  $ test-snapd-pulseaudio.play --help  # ensure SNAP dirs are created
  ...

  $ sudo cp /usr/share/sounds/alsa/Noise.wav /var/snap/test-snapd-
  pulseaudio/common/

  $ test-snapd-pulseaudio.play /var/snap/test-snapd-pulseaudio/common/Noise.wav 
&& echo yes
  xcb_connection_has_error() returned true
  yes

  (note, the xcb_connection_has_error() message is due to the x11
  interface not being connected which is unrelated to mediation. x11 is
  left out to ensure that just audio-playback/audio-record are tested)

  $ test-snapd-pulseaudio.record /tmp/out.wav && echo yes # should pass
  ...
  ^Cyes

  $ test-snapd-pulseaudio.play /tmp/out.wav && echo yes
  ...
  yes

  For strict snaps with audio-playback/audio-record:
  $ sudo snap refresh core --candidate 

[Touch-packages] [Bug 1781428] Re: please enable snap mediation support

2020-04-17 Thread Jamie Strandboge
** Description changed:

  [Impact]
  Ubuntu 16.10 added rudimentary snap support to disable audio recording if the 
connecting process was a snap. By Ubuntu 18.04, something changed in the build 
resulting in 'Enable Snappy support: no' with audio recording no longer being 
mediated by pulseaudio (access to the pulseaudio socket continued to be 
mediated by snapd's apparmor policy). This resulted in any application with the 
pulseaudio interface connected to be able to also record. Ubuntu 16.04 never 
had mediation patches and always allowed recording when the pulseaudio 
interface was connected.
  
  To correct this situation but not regress existing behavior, Ubuntu
  19.04's pulseaudio was updated patch to allow playback to all connected
  clients (snaps or not), record by classic snaps (see bug 1787324) and
  record by strict mode snaps if either the pulseaudio or new-in-
  snapd-2.41 audio-record interfaces were connected. With this change,
  snapd is in a position to migrate snaps to the new audio-playback and
  audio-record interfaces and properly mediate audio recording (see
  https://forum.snapcraft.io/t/upcoming-pulseaudio-interface-
  deprecation/13418).
  
  The patch to pulseaudio consists of adding a module, enabling it in
  default.pa and then when it is enabled, pulseaudio when faced with a
  record operation will, when the connecting process is a snap (ie, its
  security label (ie, apparmor label) starts with 'snap.'), query snapd
  via its control socket to ask if the snap is classic and if not, whether
  the pulseaudio or audio-record interfaces are connected. Adjusting
  pulseaudio in the manner does not require coordination with any release
  of snapd. It does need a newer version of snapd-glib, which was recently
  updated to 1.49 in the last SRU.
  
  [Test Case]
  
  IMPORTANT: if updating pulseaudio while the session is running, either
  need to reboot for the test or kill pulseaudio so it can restart with
  the new snap policy
  
  For unconfined applications:
  $ paplay /usr/share/sounds/alsa/Noise.wav && echo "yes"
  yes
  
  $ rm -f /tmp/out.wav ; parecord /tmp/out.wav && echo "yes"  # ctrl-c to stop 
recording
  ^Cyes
  
  $ paplay /tmp/out.wav && echo "yes"
  yes
  
  For confined, non-snap applications:
  $ sudo apt-get install evince
  
  $ aa-exec -p /usr/bin/evince -- paplay /usr/share/sounds/alsa/Noise.wav
  && echo yes
  
  $ rm -f /tmp/out.wav ; aa-exec -p /usr/bin/evince -- parecord /tmp/out.wav && 
echo "yes"  # ctrl-c to stop recording
  ^Cyes
  
  $ aa-exec -p /usr/bin/evince -- paplay /tmp/out.wav && echo "yes"
  yes
  
  For classic snaps:
  $ sudo snap install test-snapd-classic-confinement --classic
  
  $ snap run --shell test-snapd-classic-confinement
  
  $ cat /proc/self/attr/current   # verify we are classic confined
  snap.test-snapd-classic-confinement.test-snapd-classic-confinement (complain)
  
  $ paplay /usr/share/sounds/alsa/Noise.wav && echo "yes"
  yes
  
  $ rm -f /tmp/out.wav ; parecord /tmp/out.wav && echo "yes"  # ctrl-c to stop 
recording
  ^Cyes
  
  $ paplay /tmp/out.wav && echo "yes"
  yes
  
  $ exit # out of snap run --shell
  
  For strict snaps with pulseaudio:
  $ sudo snap install test-snapd-pulseaudio --edge
+ $ sudo snap connect test-snapd-pulseaudio:pulseaudio
  
  $ snap connections test-snapd-pulseaudio
  Interface   Plug  Slot Notes
  pulseaudio  test-snapd-pulseaudio:pulseaudio  :pulseaudio  -
  
  $ test-snapd-pulseaudio.play --help  # ensure SNAP dirs are created
  ...
  
  $ sudo cp /usr/share/sounds/alsa/Noise.wav /var/snap/test-snapd-
  pulseaudio/common/
  
  $ test-snapd-pulseaudio.play /var/snap/test-snapd-pulseaudio/common/Noise.wav 
&& echo yes
  xcb_connection_has_error() returned true
  yes
  
  (note, the xcb_connection_has_error() message is due to the x11
- interface not being connecting which is unrelated to mediation. x11 is
+ interface not being connected which is unrelated to mediation. x11 is
  left out to ensure that just audio-playback/audio-record are tested)
  
  $ test-snapd-pulseaudio.record /tmp/out.wav && echo yes # should pass
  ...
  ^Cyes
  
  $ test-snapd-pulseaudio.play /tmp/out.wav && echo yes
  ...
  yes
  
  For strict snaps with audio-playback/audio-record:
  $ sudo snap refresh core --candidate # make sure have 2.41. 'install' on 16.04
  $ sudo snap install test-snapd-audio-record --edge
  
  $ snap connections test-snapd-audio-record  # record not connected
  Interface   PlugSlot Notes
  audio-playback  test-snapd-audio-record:audio-playback  :audio-playback  -
  audio-recordtest-snapd-audio-record:audio-record--
  
  $ test-snapd-audio-record.play --help  # ensure SNAP dirs are created
  ...
  
  $ sudo cp /usr/share/sounds/alsa/Noise.wav /var/snap/test-snapd-audio-
  record/common/
  
  $ test-snapd-audio-record.play 
/var/snap/test-snapd-audio-record/common/Noise.wav && 

[Touch-packages] [Bug 1871148] Re: services start before apparmor profiles are loaded

2020-04-10 Thread Jamie Strandboge
Adding a snapd Ubuntu task, marking as In Progress and assigning to mvo
since he is preparing a 20.04 upload.

** Also affects: snapd (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: snapd (Ubuntu Focal)
 Assignee: (unassigned) => Michael Vogt (mvo)

** Changed in: snapd (Ubuntu Focal)
   Status: New => In Progress

** Changed in: snapd (Ubuntu Focal)
   Importance: Undecided => High

** Changed in: snapd (Ubuntu Focal)
Milestone: None => ubuntu-20.04

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

Title:
  services start before apparmor profiles are loaded

Status in AppArmor:
  Invalid
Status in snapd:
  Fix Released
Status in apparmor package in Ubuntu:
  Fix Released
Status in snapd package in Ubuntu:
  In Progress
Status in zsys package in Ubuntu:
  Invalid
Status in apparmor source package in Focal:
  Fix Released
Status in snapd source package in Focal:
  In Progress
Status in zsys source package in Focal:
  Invalid

Bug description:
  Per discussion with Zyga in #snapd on Freenode, I have hit a race
  condition where services are being started by the system before
  apparmor has been started. I have a complete log of my system showing
  the effect somewhere within at https://paste.ubuntu.com/p/Jyx6gfFc3q/.
  Restarting apparmor using `sudo systemctl restart apparmor` is enough
  to bring installed snaps back to full functionality.

  Previously, when running any snap I would receive the following in the
  terminal:

  ---
  cannot change profile for the next exec call: No such file or directory
  snap-update-ns failed with code 1: File exists
  ---

  Updated to add for Jamie:

  $ snap version
  snap2.44.2+20.04
  snapd   2.44.2+20.04
  series  16
  ubuntu  20.04
  kernel  5.4.0-21-generic

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1871148/+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-10 Thread Jamie Strandboge
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.

-- 
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 1870729] Re: DHCP Server regularly killed code=killed, status=6/ABRT

2020-04-10 Thread Jamie Strandboge
I will update the policy for the write access. I suggest removing the
crash file in /var/crash, then if you see the crash again, file a new
bug with the crash information (eg, apport-cli if on a server) so it can
be analyzed.

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

Title:
  DHCP Server regularly killed code=killed, status=6/ABRT

Status in isc-dhcp package in Ubuntu:
  In Progress

Bug description:
  On Ubuntu 20.04 The idc-dhcp- server version is
  isc-dhcp-server:
Installed: (none)
Candidate: 4.4.1-2.1ubuntu3
Version table:
   4.4.1-2.1ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages

  
  The DHCP server is being regularly killed, when searching google the  bug 
looks very similar to an older bug regarding accessing a lease file, that was 
fixed year ago. As a temporary fix in systemd I have enabled a restart every 
time the main process fails. The error got worse when i start to run a pair of 
dhcp servers syncing state between each other

  
  I regularly see the following in the syslog

  Apr  4 00:04:55 gw sh[1500]: ../../../../lib/isc/unix/socket.c:3361: 
INSIST(!sock->pending_send) failed, back trace
  Apr  4 00:04:55 gw sh[1500]: #0 0x7f36befeda4a in ??
  Apr  4 00:04:55 gw sh[1500]: #1 0x7f36befed980 in ??
  Apr  4 00:04:55 gw sh[1500]: #2 0x7f36bf0297e1 in ??
  Apr  4 00:04:55 gw sh[1500]: #3 0x7f36bedd0609 in ??
  Apr  4 00:04:55 gw sh[1500]: #4 0x7f36bef0c153 in ??
  Apr  4 00:04:55 gw systemd[1]: isc-dhcp-server.service: Main process exited, 
code=killed, status=6/ABRT
  Apr  4 00:04:55 gw systemd[1]: isc-dhcp-server.service: Failed with result 
'signal'.
  Apr  4 00:05:00 gw systemd[1]: isc-dhcp-server.service: Scheduled restart 
job, restart counter is at 3.
  Apr  4 00:05:00 gw systemd[1]: Stopped ISC DHCP IPv4 server.
  Apr  4 00:05:00 gw systemd[1]: Started ISC DHCP IPv4 server.
  Apr  4 00:05:00 gw kernel: [ 3508.161248] audit: type=1400 
audit(1585958700.678:46): apparmor="DENIED" operation="open" 
profile="/usr/sbin/dhcpd" name="/proc/2049/task/2068/comm" pid=2049 
comm="dhcpd" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
  Apr  4 00:05:00 gw dhcpd[2049]: Internet Systems Consortium DHCP Server 4.4.1
  Apr  4 00:05:00 gw sh[2049]: Internet Systems Consortium DHCP Server 4.4.1
  Apr  4 00:05:00 gw sh[2049]: Copyright 2004-2018 Internet Systems Consortium.
  Apr  4 00:05:00 gw sh[2049]: All rights reserved.
  Apr  4 00:05:00 gw sh[2049]: For info, please visit 
https://www.isc.org/software/dhcp/
  Apr  4 00:05:00 gw dhcpd[2049]: Copyright 2004-2018 Internet Systems 
Consortium.
  Apr  4 00:05:00 gw dhcpd[2049]: All rights reserved.
  Apr  4 00:05:00 gw dhcpd[2049]: For info, please visit 
https://www.isc.org/software/dhcp/
  Apr  4 00:05:00 gw kernel: [ 3508.161561] audit: type=1400 
audit(1585958700.678:47): apparmor="DENIED" operation="open" 
profile="/usr/sbin/dhcpd" name="/proc/2049/task/2069/comm" pid=2049 
comm="dhcpd" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
  Apr  4 00:05:00 gw kernel: [ 3508.161563] audit: type=1400 
audit(1585958700.682:48): apparmor="DENIED" operation="open" 
profile="/usr/sbin/dhcpd" name="/proc/2049/task/2070/comm" pid=2049 
comm="dhcpd" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
  Apr  4 00:05:00 gw dhcpd[2049]: Config file: /etc/dhcp/dhcpd.conf
  Apr  4 00:05:00 gw sh[2049]: Config file: /etc/dhcp/dhcpd.conf
  Apr  4 00:05:00 gw sh[2049]: Database file: /var/lib/dhcp/dhcpd.leases
  Apr  4 00:05:00 gw sh[2049]: PID file: /run/dhcp-server/dhcpd.pid
  Apr  4 00:05:00 gw dhcpd[2049]: Database file: /var/lib/dhcp/dhcpd.leases
  Apr  4 00:05:00 gw dhcpd[2049]: PID file: /run/dhcp-server/dhcpd.pid
  Apr  4 00:05:00 gw dhcpd[2049]: Wrote 0 deleted host decls to leases file.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1870729/+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 1871615] Re: package apparmor 2.13.3-7ubuntu4 failed to install/upgrade: end of file on stdin at conffile prompt

2020-04-10 Thread Jamie Strandboge
Thanks!

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

Title:
  package apparmor 2.13.3-7ubuntu4 failed to install/upgrade: end of
  file on stdin at conffile prompt

Status in apparmor package in Ubuntu:
  Invalid
Status in unattended-upgrades package in Ubuntu:
  Incomplete

Bug description:
  I have no definite idea what happened, it just popped up randomly.

  I can only assume it was trying to show the usual update notification

  ProblemType: Package
  DistroRelease: Ubuntu 20.04
  Package: apparmor 2.13.3-7ubuntu4
  ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27
  Uname: Linux 5.4.0-21-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.11-0ubuntu24
  AptOrdering:
   apparmor:amd64: Install
   NULL: ConfigurePending
  Architecture: amd64
  Date: Wed Apr  8 13:57:33 2020
  ErrorMessage: end of file on stdin at conffile prompt
  InstallationDate: Installed on 2020-03-25 (13 days ago)
  InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200324)
  ProcKernelCmdline: BOOT_IMAGE=/boot/vmlinuz-5.4.0-21-generic 
root=UUID=66ca0e88-1f73-48ce-a0ae-cfa14442ffe1 ro quiet splash vt.handoff=7
  Python3Details: /usr/bin/python3.8, Python 3.8.2, python3-minimal, 
3.8.2-0ubuntu2
  PythonDetails: N/A
  RelatedPackageVersions:
   dpkg 1.19.7ubuntu3
   apt  2.0.1ubuntu1
  SourcePackage: apparmor
  Syslog:
   Apr  8 13:04:35 sebipc dbus-daemon[1090]: [system] AppArmor D-Bus mediation 
is enabled
   Apr  8 13:04:44 sebipc dbus-daemon[1479]: [session uid=125 pid=1479] 
AppArmor D-Bus mediation is enabled
   Apr  8 13:05:16 sebipc dbus-daemon[2072]: [session uid=1000 pid=2072] 
AppArmor D-Bus mediation is enabled
   Apr  8 13:55:52 sebipc dbus-daemon[2072]: apparmor="DENIED" 
operation="dbus_method_call"  bus="session" path="/" 
interface="org.freedesktop.DBus.Introspectable" member="Introspect" mask="send" 
name="com.canonical.Unity" pid=11890 
label="snap.telegram-desktop.telegram-desktop" peer_pid=2359 
peer_label="unconfined"
   Apr  8 13:55:53 sebipc dbus-daemon[2072]: apparmor="DENIED" 
operation="dbus_method_call"  bus="session" path="/org/freedesktop/ScreenSaver" 
interface="org.freedesktop.ScreenSaver" member="GetSessionIdleTime" mask="send" 
name="org.freedesktop.ScreenSaver" pid=11890 
label="snap.telegram-desktop.telegram-desktop" peer_pid=2462 
peer_label="unconfined"
  Title: package apparmor 2.13.3-7ubuntu4 failed to install/upgrade: end of 
file on stdin at conffile prompt
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.apparmor.d.abstractions.base: 2020-03-26T13:00:28.401582

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1871615/+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 1871615] Re: package apparmor 2.13.3-7ubuntu4 failed to install/upgrade: end of file on stdin at conffile prompt

2020-04-09 Thread Jamie Strandboge
Foundations, it seems like unattended-upgrades should be smarter with
conffile changes (honestly, I thought it was)? Note, the security also
saw this in https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1871261.
Is this a regression?

** Also affects: unattended-upgrades (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  package apparmor 2.13.3-7ubuntu4 failed to install/upgrade: end of
  file on stdin at conffile prompt

Status in apparmor package in Ubuntu:
  Invalid
Status in unattended-upgrades package in Ubuntu:
  New

Bug description:
  I have no definite idea what happened, it just popped up randomly.

  I can only assume it was trying to show the usual update notification

  ProblemType: Package
  DistroRelease: Ubuntu 20.04
  Package: apparmor 2.13.3-7ubuntu4
  ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27
  Uname: Linux 5.4.0-21-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.11-0ubuntu24
  AptOrdering:
   apparmor:amd64: Install
   NULL: ConfigurePending
  Architecture: amd64
  Date: Wed Apr  8 13:57:33 2020
  ErrorMessage: end of file on stdin at conffile prompt
  InstallationDate: Installed on 2020-03-25 (13 days ago)
  InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200324)
  ProcKernelCmdline: BOOT_IMAGE=/boot/vmlinuz-5.4.0-21-generic 
root=UUID=66ca0e88-1f73-48ce-a0ae-cfa14442ffe1 ro quiet splash vt.handoff=7
  Python3Details: /usr/bin/python3.8, Python 3.8.2, python3-minimal, 
3.8.2-0ubuntu2
  PythonDetails: N/A
  RelatedPackageVersions:
   dpkg 1.19.7ubuntu3
   apt  2.0.1ubuntu1
  SourcePackage: apparmor
  Syslog:
   Apr  8 13:04:35 sebipc dbus-daemon[1090]: [system] AppArmor D-Bus mediation 
is enabled
   Apr  8 13:04:44 sebipc dbus-daemon[1479]: [session uid=125 pid=1479] 
AppArmor D-Bus mediation is enabled
   Apr  8 13:05:16 sebipc dbus-daemon[2072]: [session uid=1000 pid=2072] 
AppArmor D-Bus mediation is enabled
   Apr  8 13:55:52 sebipc dbus-daemon[2072]: apparmor="DENIED" 
operation="dbus_method_call"  bus="session" path="/" 
interface="org.freedesktop.DBus.Introspectable" member="Introspect" mask="send" 
name="com.canonical.Unity" pid=11890 
label="snap.telegram-desktop.telegram-desktop" peer_pid=2359 
peer_label="unconfined"
   Apr  8 13:55:53 sebipc dbus-daemon[2072]: apparmor="DENIED" 
operation="dbus_method_call"  bus="session" path="/org/freedesktop/ScreenSaver" 
interface="org.freedesktop.ScreenSaver" member="GetSessionIdleTime" mask="send" 
name="org.freedesktop.ScreenSaver" pid=11890 
label="snap.telegram-desktop.telegram-desktop" peer_pid=2462 
peer_label="unconfined"
  Title: package apparmor 2.13.3-7ubuntu4 failed to install/upgrade: end of 
file on stdin at conffile prompt
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.apparmor.d.abstractions.base: 2020-03-26T13:00:28.401582

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1871615/+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 1871615] Re: package apparmor 2.13.3-7ubuntu4 failed to install/upgrade: end of file on stdin at conffile prompt

2020-04-09 Thread Jamie Strandboge
Per https://launchpadlibrarian.net/473598993/DpkgHistoryLog.txt,
unattended-upgrades is running on this system.

Per
https://launchpadlibrarian.net/473598999/modified.conffile..etc.apparmor.d.abstractions.base.txt,
/etc/apparmor.d/abstraction/base was modified to include:

  # adds networking to all snaps
  network inet,
  network inet6,

Per https://launchpadlibrarian.net/473598994/DpkgTerminalLog.txt, as
part of the upgrade, a prompt was presented:

Configuration file '/etc/apparmor.d/abstractions/base'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
Y or I  : install the package maintainer's version
N or O  : keep your currently-installed version
  D : show the differences between the versions
  Z : start a shell to examine the situation
 The default action is to keep your current version.
*** base (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing package apparmor 
(--configure):
 end of file on stdin at conffile prompt

but since the upgrade was unattended, the prompt went unanswered.

You should be able to set things right again with: sudo apt-get -f
install

This is not a bug in the apparmor package, so marking this task as
Invalid.

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

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

Title:
  package apparmor 2.13.3-7ubuntu4 failed to install/upgrade: end of
  file on stdin at conffile prompt

Status in apparmor package in Ubuntu:
  Invalid

Bug description:
  I have no definite idea what happened, it just popped up randomly.

  I can only assume it was trying to show the usual update notification

  ProblemType: Package
  DistroRelease: Ubuntu 20.04
  Package: apparmor 2.13.3-7ubuntu4
  ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27
  Uname: Linux 5.4.0-21-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.11-0ubuntu24
  AptOrdering:
   apparmor:amd64: Install
   NULL: ConfigurePending
  Architecture: amd64
  Date: Wed Apr  8 13:57:33 2020
  ErrorMessage: end of file on stdin at conffile prompt
  InstallationDate: Installed on 2020-03-25 (13 days ago)
  InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200324)
  ProcKernelCmdline: BOOT_IMAGE=/boot/vmlinuz-5.4.0-21-generic 
root=UUID=66ca0e88-1f73-48ce-a0ae-cfa14442ffe1 ro quiet splash vt.handoff=7
  Python3Details: /usr/bin/python3.8, Python 3.8.2, python3-minimal, 
3.8.2-0ubuntu2
  PythonDetails: N/A
  RelatedPackageVersions:
   dpkg 1.19.7ubuntu3
   apt  2.0.1ubuntu1
  SourcePackage: apparmor
  Syslog:
   Apr  8 13:04:35 sebipc dbus-daemon[1090]: [system] AppArmor D-Bus mediation 
is enabled
   Apr  8 13:04:44 sebipc dbus-daemon[1479]: [session uid=125 pid=1479] 
AppArmor D-Bus mediation is enabled
   Apr  8 13:05:16 sebipc dbus-daemon[2072]: [session uid=1000 pid=2072] 
AppArmor D-Bus mediation is enabled
   Apr  8 13:55:52 sebipc dbus-daemon[2072]: apparmor="DENIED" 
operation="dbus_method_call"  bus="session" path="/" 
interface="org.freedesktop.DBus.Introspectable" member="Introspect" mask="send" 
name="com.canonical.Unity" pid=11890 
label="snap.telegram-desktop.telegram-desktop" peer_pid=2359 
peer_label="unconfined"
   Apr  8 13:55:53 sebipc dbus-daemon[2072]: apparmor="DENIED" 
operation="dbus_method_call"  bus="session" path="/org/freedesktop/ScreenSaver" 
interface="org.freedesktop.ScreenSaver" member="GetSessionIdleTime" mask="send" 
name="org.freedesktop.ScreenSaver" pid=11890 
label="snap.telegram-desktop.telegram-desktop" peer_pid=2462 
peer_label="unconfined"
  Title: package apparmor 2.13.3-7ubuntu4 failed to install/upgrade: end of 
file on stdin at conffile prompt
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.apparmor.d.abstractions.base: 2020-03-26T13:00:28.401582

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1871615/+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 1871148] Re: services start before apparmor profiles are loaded

2020-04-09 Thread Jamie Strandboge
Adding a snapd bug task.

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

Title:
  services start before apparmor profiles are loaded

Status in AppArmor:
  Invalid
Status in snapd:
  New
Status in apparmor package in Ubuntu:
  Fix Released
Status in zsys package in Ubuntu:
  Invalid
Status in apparmor source package in Focal:
  Fix Released
Status in zsys source package in Focal:
  Invalid

Bug description:
  Per discussion with Zyga in #snapd on Freenode, I have hit a race
  condition where services are being started by the system before
  apparmor has been started. I have a complete log of my system showing
  the effect somewhere within at https://paste.ubuntu.com/p/Jyx6gfFc3q/.
  Restarting apparmor using `sudo systemctl restart apparmor` is enough
  to bring installed snaps back to full functionality.

  Previously, when running any snap I would receive the following in the
  terminal:

  ---
  cannot change profile for the next exec call: No such file or directory
  snap-update-ns failed with code 1: File exists
  ---

  Updated to add for Jamie:

  $ snap version
  snap2.44.2+20.04
  snapd   2.44.2+20.04
  series  16
  ubuntu  20.04
  kernel  5.4.0-21-generic

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1871148/+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 1871148] Re: services start before apparmor profiles are loaded

2020-04-09 Thread Jamie Strandboge
Daniel, this is a different cause but same result:

zfs-load-module.service (2ms)
zfs-import-cache.service (8ms)
zfs-import.target
...
var-lib.mount (69ms)
...
snap-multipass-1869.mount (1.358s)
...
apparmor.service (279ms)
...

In this case, apparmor correctly waited for var.lib.mount, but multipass
started before apparmor.service completed.

** Also affects: snapd
   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/1871148

Title:
  services start before apparmor profiles are loaded

Status in AppArmor:
  Invalid
Status in snapd:
  New
Status in apparmor package in Ubuntu:
  Fix Released
Status in zsys package in Ubuntu:
  Invalid
Status in apparmor source package in Focal:
  Fix Released
Status in zsys source package in Focal:
  Invalid

Bug description:
  Per discussion with Zyga in #snapd on Freenode, I have hit a race
  condition where services are being started by the system before
  apparmor has been started. I have a complete log of my system showing
  the effect somewhere within at https://paste.ubuntu.com/p/Jyx6gfFc3q/.
  Restarting apparmor using `sudo systemctl restart apparmor` is enough
  to bring installed snaps back to full functionality.

  Previously, when running any snap I would receive the following in the
  terminal:

  ---
  cannot change profile for the next exec call: No such file or directory
  snap-update-ns failed with code 1: File exists
  ---

  Updated to add for Jamie:

  $ snap version
  snap2.44.2+20.04
  snapd   2.44.2+20.04
  series  16
  ubuntu  20.04
  kernel  5.4.0-21-generic

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1871148/+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 1871148] Re: services start before apparmor profiles are loaded

2020-04-08 Thread Jamie Strandboge
Daniel responded on irc and said after several reboots with the new
apparmor, everything was fine on every boot (though his critical-chain
has var.lib.mount listed).

My attached systemd-analyze plot svg shows that apparmor.service is
indeed starting after var.lib.mount on the VM where the critical-chain
didn't show it or zfs. On irc Didier thought that critical-chain would
only list the longest path to apparmor.service starting and may not show
everything (the man page isn't clear on this point IMHO).

Based on all of this, I'm going to tentatively mark the zsys task back
to Invalid. If people continue to see this bug, we can reopen as
necessary (in which case it might be a systemd task for not generating
the mount units/requires/after correctly/in a race-free manner or it
might indicate zfs initialization is perhaps slow and apparmor.service
is starting before var.lib.mount is generated (and therefore
RequiresMountsFor is satisfied. Or it is something else ;)

** Changed in: zsys (Ubuntu Focal)
   Status: New => Invalid

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

Title:
  services start before apparmor profiles are loaded

Status in AppArmor:
  Invalid
Status in apparmor package in Ubuntu:
  Fix Released
Status in zsys package in Ubuntu:
  Invalid
Status in apparmor source package in Focal:
  Fix Released
Status in zsys source package in Focal:
  Invalid

Bug description:
  Per discussion with Zyga in #snapd on Freenode, I have hit a race
  condition where services are being started by the system before
  apparmor has been started. I have a complete log of my system showing
  the effect somewhere within at https://paste.ubuntu.com/p/Jyx6gfFc3q/.
  Restarting apparmor using `sudo systemctl restart apparmor` is enough
  to bring installed snaps back to full functionality.

  Previously, when running any snap I would receive the following in the
  terminal:

  ---
  cannot change profile for the next exec call: No such file or directory
  snap-update-ns failed with code 1: File exists
  ---

  Updated to add for Jamie:

  $ snap version
  snap2.44.2+20.04
  snapd   2.44.2+20.04
  series  16
  ubuntu  20.04
  kernel  5.4.0-21-generic

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1871148/+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 1871148] Re: services start before apparmor profiles are loaded

2020-04-08 Thread Jamie Strandboge
Here is an 'sudo systemd-analyze plot > ./1871148-vm-no-varlib-
mount.svg' on a focal VM that reports the following critical-chain:

$ sudo systemd-analyze critical-chain apparmor.service
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

apparmor.service +222ms
└─local-fs.target @2.562s
  └─run-user-122.mount @4.834s
└─swap.target @1.687s
  
└─dev-disk-by\x2duuid-f5ea22a0\x2de078\x2d4d8e\x2d9412\x2d1fad2171a080.swap 
@1.663s +24ms

└─dev-disk-by\x2duuid-f5ea22a0\x2de078\x2d4d8e\x2d9412\x2d1fad2171a080.device 
@1.662s

Note that var.lib.mount is *not* listed in the critical chain. In the
svg, we see:

zfs-load-module.service (3ms)
zfs-import-cache.service (268ms)
zfs-import.target
...
var-lib.mount (156ms)
...
zfs-volume-wait.service (235ms)
...
zfs-volumes.target
...
zfs-mount.service (66ms)
local-fs.target
apparmor.service (222ms)
...

Maybe everything is fine but critical-chain has a bug?

** Attachment added: "1871148-vm-no-varlib-mount.svg"
   
https://bugs.launchpad.net/apparmor/+bug/1871148/+attachment/5349686/+files/1871148-vm-no-varlib-mount.svg

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

Title:
  services start before apparmor profiles are loaded

Status in AppArmor:
  Invalid
Status in apparmor package in Ubuntu:
  Fix Released
Status in zsys package in Ubuntu:
  New
Status in apparmor source package in Focal:
  Fix Released
Status in zsys source package in Focal:
  New

Bug description:
  Per discussion with Zyga in #snapd on Freenode, I have hit a race
  condition where services are being started by the system before
  apparmor has been started. I have a complete log of my system showing
  the effect somewhere within at https://paste.ubuntu.com/p/Jyx6gfFc3q/.
  Restarting apparmor using `sudo systemctl restart apparmor` is enough
  to bring installed snaps back to full functionality.

  Previously, when running any snap I would receive the following in the
  terminal:

  ---
  cannot change profile for the next exec call: No such file or directory
  snap-update-ns failed with code 1: File exists
  ---

  Updated to add for Jamie:

  $ snap version
  snap2.44.2+20.04
  snapd   2.44.2+20.04
  series  16
  ubuntu  20.04
  kernel  5.4.0-21-generic

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1871148/+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 1871148] Re: services start before apparmor profiles are loaded

2020-04-08 Thread Jamie Strandboge
All that said, Daniel and Jean-Baptiste, I installed 20.04 in a vm and
tried to reproduce this and could not. The apparmor change was about
correctness of the unit so I performed the upload, but I also hoped that
it would address the issue you are seeing.

I'm not certain it will. On one boot, prior to upgrading apparmor, I
saw:

$ sudo systemd-analyze critical-chain apparmor.service
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

apparmor.service +11.135s
└─local-fs.target @4.376s
  └─zfs-mount.service @4.327s +48ms
└─var-lib-dpkg.mount @4.188s +137ms
  └─var-lib.mount @3.883s +250ms
└─zfs-import.target @3.829s
  └─zfs-import-cache.service @3.125s +704ms
└─zfs-load-module.service @3.121s +2ms
  └─systemd-udev-settle.service @1.183s +1.937s
└─systemd-udev-trigger.service @933ms +248ms
  └─systemd-udevd-kernel.socket @886ms
└─system.slice @535ms
  └─-.slice @535ms

Note that var-lib.mount is already listed. On reboot though (without
updating apparmor), I see:

$ sudo systemd-analyze critical-chain apparmor.service
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

apparmor.service +101ms
└─local-fs.target @2.812s
  └─run-user-122.mount @5.172s
└─swap.target @1.823s
  
└─dev-disk-by\x2duuid-f5ea22a0\x2de078\x2d4d8e\x2d9412\x2d1fad2171a080.swap 
@1.799s +22ms

└─dev-disk-by\x2duuid-f5ea22a0\x2de078\x2d4d8e\x2d9412\x2d1fad2171a080.device 
@1.798s

Oddly, no zfs entries are listed apparently because local-fs.target
isn't pulling them in:

$ sudo systemd-analyze critical-chain local-fs.target
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

local-fs.target @2.812s
└─run-user-122.mount @5.172s
  └─swap.target @1.823s
└─dev-disk-by\x2duuid-f5ea22a0\x2de078\x2d4d8e\x2d9412\x2d1fad2171a080.swap 
@1.799s +22ms
  
└─dev-disk-by\x2duuid-f5ea22a0\x2de078\x2d4d8e\x2d9412\x2d1fad2171a080.device 
@1.798s

Looking at var-lib.mount, I see zfs is in there:

$ sudo systemd-analyze critical-chain var-lib.mount
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

var-lib.mount +179ms
└─zfs-import.target @2.248s
  └─zfs-import-cache.service @1.845s +402ms
└─zfs-load-module.service @1.840s +2ms
  └─systemd-udev-settle.service @692ms +1.143s
└─systemd-udev-trigger.service @524ms +167ms
  └─systemd-udevd-kernel.socket @494ms
└─system.slice @357ms
  └─-.slice @357ms

So why after a reboot did the dependencies change and drop the /var/lib
entry from local-fs.target?

I then upgraded apparmor to have the RequiresMountsFor
/var/lib/snapd/apparmor/profiles, rebooted and saw no difference:

$ sudo systemd-analyze critical-chain apparmor.service
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

apparmor.service +222ms
└─local-fs.target @2.562s
  └─run-user-122.mount @4.834s
└─swap.target @1.687s
  
└─dev-disk-by\x2duuid-f5ea22a0\x2de078\x2d4d8e\x2d9412\x2d1fad2171a080.swap 
@1.663s +24ms

└─dev-disk-by\x2duuid-f5ea22a0\x2de078\x2d4d8e\x2d9412\x2d1fad2171a080.device 
@1.662s


** Changed in: zsys (Ubuntu Focal)
   Status: Invalid => 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/1871148

Title:
  services start before apparmor profiles are loaded

Status in AppArmor:
  Invalid
Status in apparmor package in Ubuntu:
  Fix Released
Status in zsys package in Ubuntu:
  New
Status in apparmor source package in Focal:
  Fix Released
Status in zsys source package in Focal:
  New

Bug description:
  Per discussion with Zyga in #snapd on Freenode, I have hit a race
  condition where services are being started by the system before
  apparmor has been started. I have a complete log of my system showing
  the effect somewhere within at https://paste.ubuntu.com/p/Jyx6gfFc3q/.
  Restarting apparmor using `sudo systemctl restart apparmor` is enough
  to bring installed snaps back to full functionality.

  Previously, when running any snap I would receive the following in the
  terminal:

  ---
  cannot change profile for the next exec call: No such file or directory
  snap-update-ns failed with code 1: File exists
  ---

  Updated to add for Jamie:

  $ snap version
  snap2.44.2+20.04
  snapd   2.44.2+20.04
  series  16
  ubuntu  20.04
  kernel  5.4.0-21-generic

To manage notifications about this bug go to:

  1   2   3   4   5   6   7   8   9   10   >