[Touch-packages] [Bug 1914816] Re: ufw not logging if it decides to stop all traffic ? Confused
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
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
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)
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
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
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
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
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
@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)
** 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
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
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
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
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
** 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
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
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
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
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
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
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-*
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
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
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
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
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
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
** 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, ...)
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 #15
[Touch-packages] [Bug 1751677] Re: apparmor fails to start
** 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
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
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
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]
@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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
@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
@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
@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
@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
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
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
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
** 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
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
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
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
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
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
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
** 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
*** 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
*** 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
** 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
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
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
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
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
** 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
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
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
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
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
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
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
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
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
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
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
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 ser
[Touch-packages] [Bug 1871148] Re: services start before apparmor profiles are loaded
Marking the zsys task back to New based on my last comment. -- 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
tps://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 1870729] Re: DHCP Server regularly killed code=killed, status=6/ABRT
Now that there are no apparmor denials, this sounds like something for the server team to take a look at. Can you file a new bug since this one was used to address the apparmor denials? Thanks! -- 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 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 1871261] Re: package ufw 0.36-6 failed to install/upgrade: end of file on stdin at conffile prompt
Thank you for reporting a bug and helping to make Ubuntu better. Based on https://launchpadlibrarian.net/473334677/DpkgTerminalLog.txt: Preparing to unpack .../archives/ufw_0.36-6_all.deb ... Unpacking ufw (0.36-6) over (0.36-5) ... Setting up ufw (0.36-6) ... Configuration file '/etc/default/ufw' ==> 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. *** ufw (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing package ufw (--configure): end of file on stdin at conffile prompt Looking at https://launchpadlibrarian.net/473334680/modified.conffile..etc.default.ufw.txt I can see that the file (/etc/default/ufw) is missing the trailing newline from 0.36-5 (this file is not manipulated by the ufw command). I can't say why the file on your system was missing the trailing newline, but since it was, unattended-upgrades (seen in https://launchpadlibrarian.net/473334676/DpkgHistoryLog.txt) wasn't in a position to answer the conffile question. This is not a bug in ufw. To remedy the situation, you should be able to perform: sudo apt-get -f install. I also see that the system is running the current development release of Ubuntu. Unlike stable releases of Ubuntu, it is sometimes easier to disable unattended-upgrades when using the development release and instead run apt manually. If you disable it, feel free to re-enable it once Ubuntu 20.04 is released. Thanks again! ** 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/1871261 Title: package ufw 0.36-6 failed to install/upgrade: end of file on stdin at conffile prompt Status in ufw package in Ubuntu: Invalid Bug description: No action on my part resulted in a report problem dialog. I have never modified the ufw configuration through the life of this install, which has come from 18.04 thru 19.04 and 19.10 to arrive at 20.04. Guessing someone made a typo in packaging. ProblemType: Package DistroRelease: Ubuntu 20.04 Package: ufw 0.36-6 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: ufw:amd64: Install NULL: ConfigurePending Architecture: amd64 Date: Tue Apr 7 06:45:08 2020 ErrorMessage: end of file on stdin at conffile prompt InstallationDate: Installed on 2017-04-14 (1088 days ago) InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412) PackageArchitecture: all Python3Details: /usr/bin/python3.8, Python 3.8.2, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: /usr/bin/python2.7, Python 2.7.17, python-is-python2, 2.7.17-3 RelatedPackageVersions: dpkg 1.19.7ubuntu3 apt 2.0.1 SourcePackage: ufw Title: package ufw 0.36-6 failed to install/upgrade: end of file on stdin at conffile prompt UpgradeStatus: Upgraded to focal on 2020-04-06 (0 days ago) mtime.conffile..etc.default.ufw: 2019-07-28T20:35:23.745568 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1871261/+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 1796911] Re: libnss-systemd was denied talking to pid1
** 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/1796911 Title: libnss-systemd was denied talking to pid1 Status in apparmor package in Ubuntu: Fix Committed Bug description: cosmic apparmor 2.12-4ubuntu8 kernel 4.18.0-8-generic #9-Ubuntu I'm getting these audit messages in dmesg showing apparmor denied errors: [ 68.649187] audit: type=1107 audit(1539094926.655:32): pid=605 uid=105 auid=4294967295 ses=4294967295 subj==unconfined 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=1091 label="/usr/sbin/named" peer_pid=1 peer_label="unconfined" exe="/usr/bin/dbus-daemon" sauid=105 hostname=? addr=? terminal=?' [ 161.059989] audit: type=1107 audit(1539095018.957:33): pid=605 uid=105 auid=4294967295 ses=4294967295 subj==unconfined 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=1191 label="/usr/sbin/named" peer_pid=1 peer_label="unconfined" exe="/usr/bin/dbus-daemon" sauid=105 hostname=? addr=? terminal=?' [ 437.582034] audit: type=1107 audit(1539095295.553:34): pid=605 uid=105 auid=4294967295 ses=4294967295 subj==unconfined 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=1534 label="/usr/sbin/named" peer_pid=1 peer_label="unconfined" exe="/usr/bin/dbus-daemon" sauid=105 hostname=? addr=? terminal=?' [ 468.184231] audit: type=1107 audit(1539095326.159:35): pid=605 uid=105 auid=4294967295 ses=4294967295 subj==unconfined 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=1577 label="/usr/sbin/named" peer_pid=1 peer_label="unconfined" exe="/usr/bin/dbus-daemon" sauid=105 hostname=? addr=? terminal=?' I pinged #ubuntu-hardened, and xnox had these comments: ha ahasenack, libnss-systemd was denied talking to pid1 to query dynamicusers i think so i think something somehwere need adjustemnt to allow libnss-systemd to talk to pid1 and call GetDynamicUsers LookupDynamicUserByName LookupDynamicUserByUID GetDynamicUsers as well To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1796911/+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
4.4.1-2.1ubuntu4 was uploaded for the above. Please let us know if it doesn't fix the issue for you. ** Changed in: isc-dhcp (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 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 Committed 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 1869629] Re: please add /etc/mdns.allow to /etc/apparmor.d/abstractions/mdns
FYI, I submitted https://github.com/snapcore/snapd/pull/8443 for this. ** Changed in: snapd Status: Triaged => 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/1869629 Title: please add /etc/mdns.allow to /etc/apparmor.d/abstractions/mdns Status in snapd: In Progress Status in apparmor package in Ubuntu: Fix Released Status in chrony package in Ubuntu: Invalid Bug description: In focal users of mdns get denials in apparmor confined applications. An exampel can be found in the original bug below. It seems it is a common pattern, see https://github.com/lathiat/nss-mdns#etcmdnsallow Therefore I'm asking to add /etc/mdns.allow r, to the file /etc/apparmor.d/abstractions/mdns" by default. --- original bug --- Many repetitions of audit: type=1400 audit(1585517168.705:63): apparmor="DENIED" operation="open" profile="/usr/sbin/chronyd" name="/etc/mdns.allow" pid=1983815 comm="chronyd" requested_mask="r" denied_mask="r" fsuid=123 ouid=0 in log. I use libnss-mdns for .local name resolution, so /etc/nsswitch.conf contains hosts: files mdns [NOTFOUND=return] myhostname dns and /etc/mnds.allow contains the domains to resolve with mDNS (in may case, "local." and "local"; see /usr/share/doc/libnss- mdns/README.html.) Presumably cronyd calls a gethostbyX() somewhere, thus eventually trickling down through the name service switch and opening /etc/mdns.allow, which the AppArmor profile in the chrony package does not allow. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: chrony 3.5-6ubuntu1 ProcVersionSignature: Ubuntu 5.4.0-18.22-generic 5.4.24 Uname: Linux 5.4.0-18-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu21 Architecture: amd64 Date: Sun Mar 29 15:02:39 2020 InstallationDate: Installed on 2020-03-26 (3 days ago) InstallationMedia: Xubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200326) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: chrony UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1869629/+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
FYI, I added these accesses in https://github.com/snapcore/snapd/pull/8443 ** Also affects: snapd Importance: Undecided Status: New ** Changed in: snapd Status: New => In Progress ** Changed in: snapd 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/1869024 Title: add support for DynamicUser feature of systemd Status in snapd: In Progress Status in apparmor package in Ubuntu: In Progress 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
Does adjusting /etc/apparmor.d/usr.sbin.dhcpd to have:
owner @{PROC}/[0-9]*/comm r,
owner @{PROC}/[0-9]*/task/[0-9]*/comm r,
resolve the issue for you? Be sure to load the policy into the kernel
with: sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.dhcpd before
performing your testing.
** Changed in: isc-dhcp (Ubuntu)
Importance: Undecided => High
** Changed in: isc-dhcp (Ubuntu)
Status: New => In Progress
** Changed in: isc-dhcp (Ubuntu)
Milestone: None => ubuntu-20.04
** Changed in: isc-dhcp (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 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 1871148] Re: services start before apparmor profiles are loaded
I uploaded 2.13.3-7ubuntu4 to address this: https://launchpad.net/ubuntu/+source/apparmor/2.13.3-7ubuntu4 There might be other fixes for zsys, but this should address the issue in snapd. It is currently in unapproved, but a member of the release team will hopefully approve it soon. ** Changed in: apparmor (Ubuntu Focal) Status: In Progress => Fix Committed ** Changed in: apparmor (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 apparmor package in Ubuntu: Fix Committed Status in zsys package in Ubuntu: Confirmed Status in apparmor source package in Focal: Fix Committed Status in zsys source package in Focal: Confirmed 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 1848919] Re: [snap] Permission denied on Private encrypted folder
** Changed in: snapd Status: In Progress => Fix Released ** Changed in: snapd (Ubuntu) Status: Triaged => 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/1848919 Title: [snap] Permission denied on Private encrypted folder Status in AppArmor: Fix Released Status in snapd: Fix Released Status in apparmor package in Ubuntu: In Progress Status in chromium-browser package in Ubuntu: Invalid Status in snapd package in Ubuntu: Fix Released Bug description: When accessing the Private (/home/username/Private, Encrypted Directory) folder (e.g. via "Link save as...") it shows "Could not read contents of Private, Error opening directory ...: Permission denied" Package: chromium-browser Version: 77.0.3865.120-0ubuntu1~snap1 To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1848919/+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 1848919] Re: [snap] Permission denied on Private encrypted folder
** Changed in: apparmor Status: In Progress => Fix Released ** Also affects: apparmor (Ubuntu) Importance: Undecided Status: New ** Changed in: apparmor (Ubuntu) Importance: Undecided => Medium ** 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/1848919 Title: [snap] Permission denied on Private encrypted folder Status in AppArmor: Fix Released Status in snapd: In Progress Status in apparmor package in Ubuntu: In Progress Status in chromium-browser package in Ubuntu: Invalid Status in snapd package in Ubuntu: Triaged Bug description: When accessing the Private (/home/username/Private, Encrypted Directory) folder (e.g. via "Link save as...") it shows "Could not read contents of Private, Error opening directory ...: Permission denied" Package: chromium-browser Version: 77.0.3865.120-0ubuntu1~snap1 To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1848919/+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 1796911] Re: libnss-systemd was denied talking to pid1
** Changed in: apparmor (Ubuntu) Status: Confirmed => In Progress ** Changed in: apparmor (Ubuntu) Assignee: (unassigned) => Jamie Strandboge (jdstrand) ** Changed in: apparmor (Ubuntu) Importance: Undecided => High -- 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/1796911 Title: libnss-systemd was denied talking to pid1 Status in apparmor package in Ubuntu: In Progress Bug description: cosmic apparmor 2.12-4ubuntu8 kernel 4.18.0-8-generic #9-Ubuntu I'm getting these audit messages in dmesg showing apparmor denied errors: [ 68.649187] audit: type=1107 audit(1539094926.655:32): pid=605 uid=105 auid=4294967295 ses=4294967295 subj==unconfined 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=1091 label="/usr/sbin/named" peer_pid=1 peer_label="unconfined" exe="/usr/bin/dbus-daemon" sauid=105 hostname=? addr=? terminal=?' [ 161.059989] audit: type=1107 audit(1539095018.957:33): pid=605 uid=105 auid=4294967295 ses=4294967295 subj==unconfined 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=1191 label="/usr/sbin/named" peer_pid=1 peer_label="unconfined" exe="/usr/bin/dbus-daemon" sauid=105 hostname=? addr=? terminal=?' [ 437.582034] audit: type=1107 audit(1539095295.553:34): pid=605 uid=105 auid=4294967295 ses=4294967295 subj==unconfined 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=1534 label="/usr/sbin/named" peer_pid=1 peer_label="unconfined" exe="/usr/bin/dbus-daemon" sauid=105 hostname=? addr=? terminal=?' [ 468.184231] audit: type=1107 audit(1539095326.159:35): pid=605 uid=105 auid=4294967295 ses=4294967295 subj==unconfined 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=1577 label="/usr/sbin/named" peer_pid=1 peer_label="unconfined" exe="/usr/bin/dbus-daemon" sauid=105 hostname=? addr=? terminal=?' I pinged #ubuntu-hardened, and xnox had these comments: ha ahasenack, libnss-systemd was denied talking to pid1 to query dynamicusers i think so i think something somehwere need adjustemnt to allow libnss-systemd to talk to pid1 and call GetDynamicUsers LookupDynamicUserByName LookupDynamicUserByUID GetDynamicUsers as well To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1796911/+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
** Changed in: apparmor (Ubuntu) Status: New => Fix Committed ** Changed in: apparmor (Ubuntu) Status: Fix Committed => In Progress ** Changed in: apparmor (Ubuntu) Importance: Undecided => High ** 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/1869024 Title: add support for DynamicUser feature of systemd Status in apparmor package in Ubuntu: In Progress Bug description: systemd offers to create dynamic (and semi-stable) users for services. This causes many services using Apparmor profiles to trigger those denials (even when they don't use the DynamicUser feature): audit: type=1107 audit(1585076282.591:30): pid=621 uid=103 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/systemd1" interface="org.freedesktop.systemd1.Manager" member="GetDynamicUsers" mask="send" name="org.freedesktop.systemd1" pid=709 label="/usr/sbin/squid" peer_pid=1 peer_label="unconfined" And more recently with systemd 245 this also get shown: audit: type=1400 audit(1585139000.628:39): apparmor="DENIED" operation="open" profile="/usr/sbin/squid" name="/run/systemd/userdb/" pid=769 comm="squid" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Additional information: # lsb_release -rd Description: Ubuntu Focal Fossa (development branch) Release: 20.04 # uname -a Linux foo.example.com 5.4.0-18-generic #22-Ubuntu SMP Sat Mar 7 18:13:06 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux # apt-cache policy apparmor squid apparmor: Installed: 2.13.3-7ubuntu2 Candidate: 2.13.3-7ubuntu2 Version table: *** 2.13.3-7ubuntu2 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status squid: Installed: 4.10-1ubuntu1 Candidate: 4.10-1ubuntu1 Version table: *** 4.10-1ubuntu1 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1869024/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1871148] Re: services start before apparmor profiles are loaded
Reassigning the snapd task to apparmor in Ubuntu since it has a patch to rc.apparmor.functions to look for /var/lib/snapd/apparmor/profiles but does not add it to RequiresMountsFor. ** Project changed: snapd => apparmor ** Changed in: apparmor Status: Confirmed => In Progress ** Changed in: apparmor Importance: Critical => Undecided ** Changed in: apparmor Status: In Progress => Invalid ** Also affects: apparmor (Ubuntu) Importance: Undecided Status: New ** Changed in: apparmor (Ubuntu Focal) Status: New => In Progress ** Changed in: apparmor (Ubuntu Focal) Importance: Undecided => Critical ** Changed in: apparmor (Ubuntu Focal) 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/1871148 Title: services start before apparmor profiles are loaded Status in AppArmor: Invalid Status in apparmor package in Ubuntu: In Progress Status in zsys package in Ubuntu: Confirmed Status in apparmor source package in Focal: In Progress Status in zsys source package in Focal: Confirmed 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
