[Touch-packages] [Bug 1904068] [NEW] apt(-get) source fails to use credentials from /etc/apt/auth.conf(.d)
Public bug reported: I have configured apt-src access to the private ESM PPAs via entries in /etc/apt/sources.list.d/ubuntu-security.list as follows: deb-src https://private-ppa.launchpad.net/ubuntu-esm/esm-infra- security/ubuntu trusty main and then added credentials as follows to /etc/apt/auth.conf.d/ubuntu- security.conf: machine private-ppa.launchpad.net/ubuntu-esm/esm-infra-security/ubuntu login alexmurray password Running apt-get update then succeeds - but if I then try and run `apt- get source` to download from the PPA it fails: $ apt-get source --only-source intel-microcode/trusty Reading package lists... Done Selected version '3.20201110.0ubuntu0.14.04.2' (trusty) for intel-microcode NOTICE: 'intel-microcode' packaging is maintained in the 'Git' version control system at: https://salsa.debian.org/hmh/intel-microcode.git Please use: git clone https://salsa.debian.org/hmh/intel-microcode.git to retrieve the latest (possibly unreleased) updates to the package. Need to get 3,447 kB of source archives. Err:1 https://private-ppa.launchpad.net/ubuntu-esm/esm-infra-security/ubuntu trusty/main intel-microcode 3.20201110.0ubuntu0.14.04.2 (tar) 401 Unauthorized [IP: 2001:67c:1560:8008::15 443] Err:2 https://private-ppa.launchpad.net/ubuntu-esm/esm-infra-security/ubuntu trusty/main intel-microcode 3.20201110.0ubuntu0.14.04.2 (dsc) 401 Unauthorized [IP: 2001:67c:1560:8008::15 443] E: Failed to fetch https://private-ppa.launchpad.net/ubuntu-esm/esm-infra-security/ubuntu/pool/main/i/intel-microcode/intel-microcode_3.20201110.0ubuntu0.14.04.2.tar.xz 401 Unauthorized [IP: 2001:67c:1560:8008::15 443] E: Failed to fetch https://private-ppa.launchpad.net/ubuntu-esm/esm-infra-security/ubuntu/pool/main/i/intel-microcode/intel-microcode_3.20201110.0ubuntu0.14.04.2.dsc 401 Unauthorized [IP: 2001:67c:1560:8008::15 443] E: Failed to fetch some archives. However if I edit /etc/apt/sources.list.d/ubuntu-security.list above to specify the credentials in-line then it succeeds: deb-src https://alexmurray:x...@private-ppa.launchpad.net/ubuntu-esm /esm-infra-security/ubuntu trusty main $ apt-get source --only-source intel-microcode/trusty Reading package lists... Done Selected version '3.20201110.0ubuntu0.14.04.2' (trusty) for intel-microcode NOTICE: 'intel-microcode' packaging is maintained in the 'Git' version control system at: https://salsa.debian.org/hmh/intel-microcode.git Please use: git clone https://salsa.debian.org/hmh/intel-microcode.git to retrieve the latest (possibly unreleased) updates to the package. Need to get 3,447 kB of source archives. Get:1 https://private-ppa.launchpad.net/ubuntu-esm/esm-infra-security/ubuntu trusty/main intel-microcode 3.20201110.0ubuntu0.14.04.2 (tar) [3,446 kB] Get:2 https://private-ppa.launchpad.net/ubuntu-esm/esm-infra-security/ubuntu trusty/main intel-microcode 3.20201110.0ubuntu0.14.04.2 (dsc) [1,604 B] Fetched 3,447 kB in 5s (657 kB/s) dpkg-source: info: extracting intel-microcode in intel-microcode-3.20201110.0ubuntu0.14.04.2 dpkg-source: info: unpacking intel-microcode_3.20201110.0ubuntu0.14.04.2.tar.xz However now apt(-get) update complains about having credentials manually listed in the apt sources: $ sudo apt update ... N: Usage of apt_auth.conf(5) should be preferred over embedding login information directly in the sources.list(5) entry for 'https://private-ppa.launchpad.net/ubuntu-esm/esm-infra-security/ubuntu' ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: apt 2.1.10 ProcVersionSignature: Ubuntu 5.8.0-28.30-generic 5.8.14 Uname: Linux 5.8.0-28-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu50 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Fri Nov 13 09:09:54 2020 InstallationDate: Installed on 2020-10-11 (32 days ago) InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Beta amd64 (20200930) SourcePackage: apt UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: apt (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug groovy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1904068 Title: apt(-get) source fails to use credentials from /etc/apt/auth.conf(.d) Status in apt package in Ubuntu: New Bug description: I have configured apt-src access to the private ESM PPAs via entries in /etc/apt/sources.list.d/ubuntu-security.list as follows: deb-src https://private-ppa.launchpad.net/ubuntu-esm/esm-infra- security/ubuntu trusty main and then added credentials as follows to /etc/apt/auth.conf.d/ubuntu- security.conf: machine private-ppa.launchpad.net/ubuntu-esm/esm-infra-security/ubuntu login alexmurray password Running apt-get update then succeeds - but if I then try and run `apt- get source` to download f
[Touch-packages] [Bug 1898547] Re: neutron-linuxbridge-agent fails to start with iptables 1.8.5
** Tags removed: verification-needed -- 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 Ubuntu on IBM z Systems: Fix Committed Status in iptables package in Ubuntu: Fix Released Status in neutron package in Ubuntu: Invalid Status in iptables source package in Groovy: Fix Committed Status in neutron source package in Groovy: Invalid Status in iptables source package in Hirsute: Fix Released Status in neutron source package in Hirsute: Invalid Bug description: [Impact] With iptables 1.8.5 neutron-linuxbridge-agent fails to properly start. 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 This can be demonstrated with a simple test case: iptables-restore
[Touch-packages] [Bug 1898547] Re: neutron-linuxbridge-agent fails to start with iptables 1.8.5
jdstrand sponsored this to groovy-proposed and autopkgtests have all passed - ~ubuntu-sru - could you please review? -- 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 Ubuntu on IBM z Systems: Fix Committed Status in iptables package in Ubuntu: Fix Released Status in neutron package in Ubuntu: Invalid Status in iptables source package in Groovy: Fix Committed Status in neutron source package in Groovy: Invalid Status in iptables source package in Hirsute: Fix Released Status in neutron source package in Hirsute: Invalid Bug description: [Impact] With iptables 1.8.5 neutron-linuxbridge-agent fails to properly start. 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 This can be demonstrated with a simple test case: iptables-restore
[Touch-packages] [Bug 1904288] Re: package bluez 5.53-0ubuntu3 failed to install/upgrade: il sottoprocesso installato pacchetto bluez script post-installation ha restituito lo stato di errore 1
Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find. ** Information type changed from Private Security to Public -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1904288 Title: package bluez 5.53-0ubuntu3 failed to install/upgrade: il sottoprocesso installato pacchetto bluez script post-installation ha restituito lo stato di errore 1 Status in bluez package in Ubuntu: New Bug description: I seguenti pacchetti sono stati installati automaticamente e non sono più richiesti: libbluetooth3-dbg libfprint-2-tod1 libsbc1 linux-headers-5.4.0-47 linux-headers-5.4.0-47-generic linux-image-5.4.0-47-generic linux-modules-5.4.0-47-generic linux-modules-extra-5.4.0-47-generic Usare "sudo apt autoremove" per rimuoverli. I seguenti pacchetti saranno RIMOSSI: bluez* bluez-btsco* bluez-dbg* gnome-bluetooth* pulseaudio-module-bluetooth* 0 aggiornati, 0 installati, 5 da rimuovere e 93 non aggiornati. Dopo quest'operazione, verranno liberati 14,9 MB di spazio su disco. Continuare? [S/n] s (Lettura del database... 226489 file e directory attualmente installati.) Rimozione di pulseaudio-module-bluetooth (1:13.99.1-1ubuntu3.7)... Rimozione di gnome-bluetooth (3.34.1-1)... Rimozione di bluez-btsco (1:0.50-0ubuntu7)... Rimozione di bluez-dbg (5.53-0ubuntu3)... Rimozione di bluez (5.53-0ubuntu3)... Elaborazione dei trigger per mime-support (3.64ubuntu1)... Elaborazione dei trigger per hicolor-icon-theme (0.17-2)... Elaborazione dei trigger per gnome-menus (3.36.0-1ubuntu1)... Elaborazione dei trigger per man-db (2.9.1-1)... Elaborazione dei trigger per dbus (1.12.16-2ubuntu2.1)... Elaborazione dei trigger per desktop-file-utils (0.24-1ubuntu3)... (Lettura del database... 226307 file e directory attualmente installati.) Eliminazione dei file di configurazione di bluez (5.53-0ubuntu3)... dpkg: attenzione: nel rimuovere bluez, la directory "/var/lib/bluetooth" è risul tata non vuota e non viene rimossa Elaborazione dei trigger per dbus (1.12.16-2ubuntu2.1)... Elaborazione dei trigger per systemd (245.4-4ubuntu3.2)... Lettura elenco dei pacchetti... Fatto Generazione albero delle dipendenze Lettura informazioni sullo stato... Fatto I seguenti pacchetti sono stati installati automaticamente e non sono più richiesti: libbluetooth3-dbg libfprint-2-tod1 libsbc1 linux-headers-5.4.0-47 linux-headers-5.4.0-47-generic linux-image-5.4.0-47-generic linux-modules-5.4.0-47-generic linux-modules-extra-5.4.0-47-generic Usare "sudo apt autoremove" per rimuoverli. I seguenti pacchetti NUOVI saranno installati: bluez 0 aggiornati, 1 installati, 0 da rimuovere e 93 non aggiornati. È necessario scaricare 981 kB di archivi. Dopo quest'operazione, verranno occupati 4.910 kB di spazio su disco. Scaricamento di:1 http://it.archive.ubuntu.com/ubuntu focal/main amd64 bluez amd64 5.53-0ubuntu3 [981 kB] Recuperati 981 kB in 1s (985 kB/s) Selezionato il pacchetto bluez non precedentemente selezionato. (Lettura del database... 226300 file e directory attualmente installati.) Preparativi per estrarre .../bluez_5.53-0ubuntu3_amd64.deb... Estrazione di bluez (5.53-0ubuntu3)... Configurazione di bluez (5.53-0ubuntu3)... Created symlink /etc/systemd/system/dbus-org.bluez.service → /lib/systemd/system /bluetooth.service. Created symlink /etc/systemd/system/bluetooth.target.wants/bluetooth.service → / lib/systemd/system/bluetooth.service. Job for bluetooth.service failed because the control process exited with error c ode. See "systemctl status bluetooth.service" and "journalctl -xe" for details. invoke-rc.d: initscript bluetooth, action "start" failed. ● bluetooth.service - Bluetooth service Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor pres et: enabled) Drop-In: /etc/systemd/system/bluetooth.service.d └─override.conf Active: activating (auto-restart) (Result: exit-code) since Sat 2020-11-14 16:59:04 CET; 21ms ago Docs: man:bluetoothd(8) Process: 14788 ExecStart=/usr/lib/bluetooth/bluetoothd --debug -n (code=exit ed, status=1/FAILURE) Main PID: 14788 (code=exited, status=1/FAILURE) Status: "Starting up" dpkg: errore nell'elaborare il pacchetto bluez (--configure): il sottoprocesso installato pacchetto bluez script post-installation ha restitu ito lo stato di errore 1 Elaborazione dei trigger per systemd (245.4-4ubuntu3.2)... Elaborazione dei
[Touch-packages] [Bug 1891953] Re: CVE-2019-8936
@rokclimb15 - are you still looking at producing debdiff's for focal + groovy as well? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1891953 Title: CVE-2019-8936 Status in ntp package in Ubuntu: Confirmed Status in ntp source package in Bionic: Fix Released Status in ntp source package in Focal: Confirmed Status in ntp source package in Groovy: Confirmed Status in ntp package in Debian: Fix Released Bug description: It was discovered that the fix for CVE-2018-7182 introduced a NULL pointer dereference into NTP. An attacker could use this vulnerability to cause a denial of service (crash). https://people.canonical.com/~ubuntu- security/cve/2019/CVE-2019-8936.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1891953/+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 1891953] Re: CVE-2019-8936
Excellent - thank you :) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1891953 Title: CVE-2019-8936 Status in ntp package in Ubuntu: Confirmed Status in ntp source package in Bionic: Fix Released Status in ntp source package in Focal: Confirmed Status in ntp source package in Groovy: Confirmed Status in ntp package in Debian: Fix Released Bug description: It was discovered that the fix for CVE-2018-7182 introduced a NULL pointer dereference into NTP. An attacker could use this vulnerability to cause a denial of service (crash). https://people.canonical.com/~ubuntu- security/cve/2019/CVE-2019-8936.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1891953/+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
Yep I'll take this @Christian ** Changed in: iptables (Ubuntu Groovy) 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: Confirmed Status in iptables source package in Groovy: New Status in iptables package in Fedora: Confirmed 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 1862348] Re: Apport lock file root privilege escalation
** 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 apport in Ubuntu.
https://bugs.launchpad.net/bugs/1862348
Title:
Apport lock file root privilege escalation
Status in Apport:
New
Status in apport package in Ubuntu:
Fix Released
Bug description:
Vulnerable source code (from data/apport):
35# create lock file directory
36try:
37os.mkdir("/var/lock/apport", mode=0o744)
38except FileExistsError as e:
39pass
40
41# create a lock file
42try:
43fd = os.open("/var/lock/apport/lock", os.O_WRONLY |
os.O_CREAT | os.O_NOFOLLOW)
44except OSError as e:
45error_log('cannot create lock file (uid %i): %s' %
(os.getuid(), str(e)))
46sys.exit(1)
When invoked, Apport tries to create the directory /var/lock/apport
and continues its execution if the directory already exists.
Since /var/lock is a world writable tmpfs, the probability that
/var/lock/apport directory doesn't exist is high, which allows a
malicious user to create a symbolic link to the directory of its
choice to control the lock file location.
In this case, os.O_NOFOLLOW and fs.protected_symlinks (sysctl) have no
effect during os.open execution because the symbolic link isn't
located in the last component of the given path.
In addition, os.open is called without specifying the "mode" optional
argument which by default is set to 0o777. Thus the lock file is
created as root and is world writable which opens the door to several
root privilege escalation scenarios like, for example, creating the
lock file in a cron scripts directory.
All releases containing the bug 1839415 fix
(https://bugs.launchpad.net/apport/+bug/1839415) are affected.
Fix suggestions:
- If the /var/lock/apport directory already exists and isn't owned by root or
owned by root but world writable, remove it and recreate it.
- Specify a mode of 0o600 in the os.open call for the lock file.
To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1862348/+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 1862933] Re: Apport crash report & cron script TOCTTOU
** 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 apport in Ubuntu.
https://bugs.launchpad.net/bugs/1862933
Title:
Apport crash report & cron script TOCTTOU
Status in Apport:
New
Status in apport package in Ubuntu:
Fix Released
Bug description:
Vulnerable code (from data/apport):
700# we prefer having a file mode of 0 while writing; this
doesn't work
701# for suid binaries as we completely drop privs and
thus can't chmod
702# them later on
703if pidstat.st_uid != os.getuid():
704mode = 0o640
705else:
706mode = 0
707reportfile = os.fdopen(os.open(report, os.O_RDWR |
os.O_CREAT | os.O_EXCL, mode), 'w+b')
708assert reportfile.fileno() > sys.stderr.fileno()
709
710# Make sure the crash reporting daemon can read this
report
711try:
712gid = pwd.getpwnam('whoopsie').pw_gid
713os.chown(report, pidstat.st_uid, gid)
714except (OSError, KeyError):
715os.chown(report, pidstat.st_uid, pidstat.st_gid)
716except (OSError, IOError) as e:
717error_log('Could not create report file: %s' % str(e))
718sys.exit(1)
The TOCTTOU takes place between the os.open and the os.chown call and
can be fully achieved thanks to the Apport cron script
(etc/cron.daily/apport):
1#!/bin/sh -e
2# clean all crash reports which are older than a week.
3[ -d /var/crash ] || exit 0
4find /var/crash/. ! -name . -prune -type f \( \( -size 0 -a \!
-name '*.upload*' -a \! -name '*.drkonqi*' \) -o -mtime +7 \) -exec rm -f --
'{}' \;
5find /var/crash/. ! -name . -prune -type d -regextype
posix-extended -regex '.*/[0-9]{12}$' \( -mtime +7 \) -exec rm -Rf -- '{}' \;
The interesting part in this daily script is that the crash reports
gets removed if their size is 0.
Since Apport drops real uid and gid, the crashed process owner can
send signals during the report file creation. At this time, effective
uid and gid are still root.
We can also block Apport by replacing user settings file with a FIFO
(~/.config/apport/settings). I'm using the FIFO way in my PoC but it
can be done without it.
To make Apport read user settings, the crashing program must not be
located in one of those directories (taken from apport/fileutils.py):
78pkg_whitelist = ['/bin/', '/boot', '/etc/', '/initrd',
'/lib', '/sbin/',
79 '/opt', '/usr/', '/var'] # packages only
ship executables in these directories
Once Apport is blocked into FIFO reading, we send the SIGSTOP signal
then we write "[main]\nunpackaged=1" into the FIFO so Apport won't
exit after resuming (if unpackaged is 0 Apport directly exits because
we're not in a "packaged" directory).
After that we "single step" through Apport by sending SIGCONT and
SIGSTOP consecutively in a loop until the report file is created with
os.open. We must make sure os.chown hasn't been called and then we
wait for the cron script to remove the report (it's created as root
with mode 0 so only root can remove it).
Once removed, we can replace it with a symbolic link/file of the same
name, resume Apport with SIGCONT then the file will now be owned by
the crashed process user and group.
I think the impact of this vulnerability alone is low because
fs.protected_symlinks prevents symlink resolution since we're in a
sticky world writable directory (/var/crash), but if it's disabled,
you can escalate privileges very easily. It still can be used in some
kind of exploit chain though.
My PoC does everything for you except symbolic link/file creation once
the report gets removed by the cron script, you have to create it
manually then press enter to resume Apport and let the chown happen.
You could also create a new crontab entry and directory then copy
Apport cron script into it so you don't have to wait the entire day.
Fix suggestions:
- Use reportfile.fileno() instead of the report string for the os.chown
calls, and also add follow_symlinks=False argument just in case.
- Remove the size 0 condition in the cron script (not sure about this one, I
suppose the condition was there for a reason).
To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1862933/+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/Li
[Touch-packages] [Bug 1860414] Re: ZDI-CAN-9867: Canonical libgsm AssertFailure
Has this been reported to the upstream libgsm developers? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libgsm in Ubuntu. https://bugs.launchpad.net/bugs/1860414 Title: ZDI-CAN-9867: Canonical libgsm AssertFailure Status in libgsm package in Ubuntu: New Bug description: ZDI-CAN-9867: Canonical libgsm AssertFailure -- CVSS - 0.0: AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N -- ABSTRACT - Trend Micro's Zero Day Initiative has identified a vulnerability affecting the following products: Libgsm - libgsm -- VULNERABILITY DETAILS Version tested: 1.0.18-2 Installer file: https://code.launchpad.net/ubuntu/+source/libgsm Platform tested: Ubuntu Analysis Please see attached documentation for full vulnerability details. gsm: src/add.c:220: word gsm_div(word, word): Assertion `num >= 0 && denum >= num' failed. -- CREDIT --- This vulnerability was discovered by: Lacne Jiang of Trend Micro -- FURTHER DETAILS -- If supporting files were contained with this report they are provided within a password protected ZIP file. The password is the ZDI candidate number in the form: ZDI-CAN- where is the ID number. Please confirm receipt of this report. We expect all vendors to remediate ZDI vulnerabilities within 120 days of the reported date. If you are ready to release a patch at any point leading up to the deadline, please coordinate with us so that we may release our advisory detailing the issue. If the 120-day deadline is reached and no patch has been made available we will release a limited public advisory with our own mitigations, so that the public can protect themselves in the absence of a patch. Please keep us updated regarding the status of this issue and feel free to contact us at any time: Zero Day Initiative zdi-disclosu...@trendmicro.com The PGP key used for all ZDI vendor communications is available from: http://www.zerodayinitiative.com/documents/disclosures-pgp-key.asc -- INFORMATION ABOUT THE ZDI Established by TippingPoint and acquired by Trend Micro, the Zero Day Initiative (ZDI) neither re-sells vulnerability details nor exploit code. Instead, upon notifying the affected product vendor, the ZDI provides its Trend Micro TippingPoint customers with zero day protection through its intrusion prevention technology. Explicit details regarding the specifics of the vulnerability are not exposed to any parties until an official vendor patch is publicly available. Please contact us for further details or refer to: http://www.zerodayinitiative.com -- DISCLOSURE POLICY Our vulnerability disclosure policy is available online at: http://www.zerodayinitiative.com/advisories/disclosure_policy/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libgsm/+bug/1860414/+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 1860414]
Thanks for taking the time to report this bug and helping to make Ubuntu better. Since the package referred to in this bug is in universe or multiverse, it is community maintained. If you are able, I suggest coordinating with upstream and posting a debdiff for this issue. When a debdiff is available, members of the security team will review it and publish the package. See the following link for more information: https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures ** Tags added: community-security -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libgsm in Ubuntu. https://bugs.launchpad.net/bugs/1860414 Title: ZDI-CAN-9867: Canonical libgsm AssertFailure Status in libgsm package in Ubuntu: New Bug description: ZDI-CAN-9867: Canonical libgsm AssertFailure -- CVSS - 0.0: AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N -- ABSTRACT - Trend Micro's Zero Day Initiative has identified a vulnerability affecting the following products: Libgsm - libgsm -- VULNERABILITY DETAILS Version tested: 1.0.18-2 Installer file: https://code.launchpad.net/ubuntu/+source/libgsm Platform tested: Ubuntu Analysis Please see attached documentation for full vulnerability details. gsm: src/add.c:220: word gsm_div(word, word): Assertion `num >= 0 && denum >= num' failed. -- CREDIT --- This vulnerability was discovered by: Lacne Jiang of Trend Micro -- FURTHER DETAILS -- If supporting files were contained with this report they are provided within a password protected ZIP file. The password is the ZDI candidate number in the form: ZDI-CAN- where is the ID number. Please confirm receipt of this report. We expect all vendors to remediate ZDI vulnerabilities within 120 days of the reported date. If you are ready to release a patch at any point leading up to the deadline, please coordinate with us so that we may release our advisory detailing the issue. If the 120-day deadline is reached and no patch has been made available we will release a limited public advisory with our own mitigations, so that the public can protect themselves in the absence of a patch. Please keep us updated regarding the status of this issue and feel free to contact us at any time: Zero Day Initiative zdi-disclosu...@trendmicro.com The PGP key used for all ZDI vendor communications is available from: http://www.zerodayinitiative.com/documents/disclosures-pgp-key.asc -- INFORMATION ABOUT THE ZDI Established by TippingPoint and acquired by Trend Micro, the Zero Day Initiative (ZDI) neither re-sells vulnerability details nor exploit code. Instead, upon notifying the affected product vendor, the ZDI provides its Trend Micro TippingPoint customers with zero day protection through its intrusion prevention technology. Explicit details regarding the specifics of the vulnerability are not exposed to any parties until an official vendor patch is publicly available. Please contact us for further details or refer to: http://www.zerodayinitiative.com -- DISCLOSURE POLICY Our vulnerability disclosure policy is available online at: http://www.zerodayinitiative.com/advisories/disclosure_policy/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libgsm/+bug/1860414/+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
When generating the list of systems calls for aarch64, libseccomp uses the generic kernel API headers rather than the architecture specific ones - and so misses the definitions of getrlimit, setrlimit and clone3 for aarch64 - if this is changed to use arch-specific headers then we can regenerate the syscalls.csv and these are now present as expected. Have submitted PRhttps://github.com/seccomp/libseccomp/pull/235 upstream for feedback. -- 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] Re: libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the getrlimit syscall on arm64
See attached for a debdiff to fix this in groovy - this backports the PR mentioned above to add these missing syscalls for aarch64. -- 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] Re: libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the getrlimit syscall on arm64
** Patch added: "libseccomp_2.4.3-1ubuntu2.debdiff" https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1877633/+attachment/5370131/+files/libseccomp_2.4.3-1ubuntu2.debdiff -- 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] Re: libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the getrlimit syscall on arm64
Tested on an up-to-date groovy install: amurray@sec-groovy-amd64:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu Groovy Gorilla (development branch) Release:20.10 Codename: groovy amurray@sec-groovy-amd64:~$ dpkg -l seccomp Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name VersionArchitecture Description +++-==-==--= ii seccomp2.4.3-1ubuntu1 amd64helper tools for high level interface to Linux seccomp filter amurray@sec-groovy-amd64:~$ scmp_sys_resolver -a aarch64 getrlimit -10180 amurray@sec-groovy-amd64:~$ scmp_sys_resolver -a aarch64 163 UNKNOWN amurray@sec-groovy-amd64:~$ sudo apt upgrade ... amurray@sec-groovy-amd64:~$ dpkg -l seccomp Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name VersionArchitecture Description +++-==-==--= ii seccomp2.4.3-1ubuntu2 amd64helper tools for high level interface to Linux seccomp filter amurray@sec-groovy-amd64:~$ scmp_sys_resolver -a aarch64 163 getrlimit amurray@sec-groovy-amd64:~$ scmp_sys_resolver -a aarch64 getrlimit 163 -- 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] Re: libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the getrlimit syscall on arm64
@jdstrand would you be willing to sponsor that for me to groovy and then I'll update this bug for SRU of this back to focal (and will add this change also for the existing libseccomp SRU for eoan/bionic/xenial in LP #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/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 1878062] Re: USB Mic (Blue Yeti) not detcted in Audacity or Ardour
For the issue of not being able to save files to / from external drives, you need to manually connect the removable-media interface for the audacity snap - so either in Ubuntu Software search again for audacity and then via the 'Permissions' button ensure the 'Read/write files on removable storage devices' is enabled - or you can go to Settings -> Applications -> Audacity and again ensure this permission is enabled. ** 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/1878062 Title: USB Mic (Blue Yeti) not detcted in Audacity or Ardour Status in apparmor package in Ubuntu: Invalid Bug description: I recently upgraded my laptop to Ubuntu 20.04 (from 19.10), which I use for recording podcasts using Audacity. The Sound Settings allow me to select the Yeti, and the monitor graphic shows lots of activity when I scratch the mic with my nails. Since the upgrade Audacity will only record from the built in mic. It's not available as a recording input at all, and selecting "default" (which is what I usually do) uses the inbuilt mic. Regardless of what the Sound Settings have selected. I tried Ardour and I could only get it to record using the built in mic. While I can select the Yeti when I start the app, I can't get it to actually register that any sound is coming in at all. I tried gnome-sound-recorder, which recorded audio from the Yeti without any issues. Unfortunately it's doesn't have any of the features I need. arecord also works with issue. I'm kinda going insane here, I've never had any issues like this before, but it suddenly seems that any halfway decent recording apps just don't want to talk to the Yeti. Is there something I'm missing, has something changed in how 20.04 handles sound devices now? Is there anything I can do to trouble shoot this? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1878062/+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 1878177] Re: CVE-2020-3810 out-of-bound stack reads in arfile
** 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 apt in Ubuntu. https://bugs.launchpad.net/bugs/1878177 Title: CVE-2020-3810 out-of-bound stack reads in arfile Status in apt package in Ubuntu: Fix Released Bug description: In https://github.com/Debian/apt/issues/111, an issue was discovered where apt's ar implementation performs (unbound) out of bound reads of a stack variable. Marking this as private security for now to avoid giving it more prominence. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1878177/+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-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base
** Summary changed: - SRU: Backport 2.4.3-1ubuntu1 from focal to eoan/bionic/xenial for newer syscalls for core20 base + SRU: Backport 2.4.3-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base -- 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-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base Status in libseccomp package in Ubuntu: New Bug description: Placeholder to start preparing SRU for https://github.com/snapcore/core20/issues/48 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1876055/+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-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base
** Patch added: "eoan" https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1876055/+attachment/5374694/+files/libseccomp_2.4.3-1ubuntu3.19.10.1.debdiff ** Patch removed: "Update for groovy solely to add the test suite change to be in-line with older releases" https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1876055/+attachment/5374692/+files/libseccomp_2.4.3-1ubuntu3.debdiff -- 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-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base Status in libseccomp package in Ubuntu: New Bug description: [Impact] snap-confine 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. [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. Any possible regressions may include applications now seeing correct system call resolution whereas previously this would have failed, and so perhaps previous failures (which were erroneous) will now be permitted. However, this was always permitted previously by the policy anyway but just denied due to this bug so it is not a true regression as such. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1876055/+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-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base
** Patch added: "bionic" https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1876055/+attachment/5374695/+files/libseccomp_2.4.3-1ubuntu3.18.04.1.debdiff -- 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-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base Status in libseccomp package in Ubuntu: New Bug description: [Impact] snap-confine 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. [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. Any possible regressions may include applications now seeing correct system call resolution whereas previously this would have failed, and so perhaps previous failures (which were erroneous) will now be permitted. However, this was always permitted previously by the policy anyway but just denied due to this bug so it is not a true regression as such. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1876055/+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-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base
** Description changed: - Placeholder to start preparing SRU for - https://github.com/snapcore/core20/issues/48 + [Impact] + + snap-confine 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. + + + [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. + + Any possible regressions may include applications now seeing correct + system call resolution whereas previously this would have failed, and so + perhaps previous failures (which were erroneous) will now be permitted. + However, this was always permitted previously by the policy anyway but + just denied due to this bug so it is not a true regression as such. ** Patch added: "Update for groovy solely to add the test suite change to be in-line with older releases" https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1876055/+attachment/5374692/+files/libseccomp_2.4.3-1ubuntu3.debdiff -- 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-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base Status in libseccomp package in Ubuntu: New Bug description: [Impact] snap-confine 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. [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 sign
[Touch-packages] [Bug 1876055] Re: SRU: Backport 2.4.3-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base
** Patch added: "focal" https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1876055/+attachment/5374693/+files/libseccomp_2.4.3-1ubuntu3.20.04.1.debdiff -- 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-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base Status in libseccomp package in Ubuntu: New Bug description: [Impact] snap-confine 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. [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. Any possible regressions may include applications now seeing correct system call resolution whereas previously this would have failed, and so perhaps previous failures (which were erroneous) will now be permitted. However, this was always permitted previously by the policy anyway but just denied due to this bug so it is not a true regression as such. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1876055/+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-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base
** Patch added: "xenial" https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1876055/+attachment/5374696/+files/libseccomp_2.4.3-1ubuntu3.16.04.1.debdiff -- 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-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base Status in libseccomp package in Ubuntu: New Bug description: [Impact] snap-confine 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. [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. Any possible regressions may include applications now seeing correct system call resolution whereas previously this would have failed, and so perhaps previous failures (which were erroneous) will now be permitted. However, this was always permitted previously by the policy anyway but just denied due to this bug so it is not a true regression as such. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1876055/+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-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base
** Patch removed: "focal" https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1876055/+attachment/5374693/+files/libseccomp_2.4.3-1ubuntu3.20.04.1.debdiff ** Patch removed: "eoan" https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1876055/+attachment/5374694/+files/libseccomp_2.4.3-1ubuntu3.19.10.1.debdiff ** Patch removed: "bionic" https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1876055/+attachment/5374695/+files/libseccomp_2.4.3-1ubuntu3.18.04.1.debdiff ** Patch removed: "xenial" https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1876055/+attachment/5374696/+files/libseccomp_2.4.3-1ubuntu3.16.04.1.debdiff -- 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-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base Status in libseccomp package in Ubuntu: New Bug description: [Impact] snap-confine 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. [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. Any possible regressions may include applications now seeing correct system call resolution whereas previously this would have failed, and so perhaps previous failures (which were erroneous) will now be permitted. However, this was always permitted previously by the policy anyway but just denied due to this bug so it is not a true regression as such. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1876055/+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-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base
** Patch added: "groovy" https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1876055/+attachment/5374698/+files/libseccomp_2.4.3-1ubuntu3.debdiff -- 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-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base Status in libseccomp package in Ubuntu: New Bug description: [Impact] snap-confine 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. [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. Any possible regressions may include applications now seeing correct system call resolution whereas previously this would have failed, and so perhaps previous failures (which were erroneous) will now be permitted. However, this was always permitted previously by the policy anyway but just denied due to this bug so it is not a true regression as such. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1876055/+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-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base
** Patch added: "libseccomp_2.4.3-1ubuntu3.20.04.1.debdiff" https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1876055/+attachment/5374699/+files/libseccomp_2.4.3-1ubuntu3.20.04.1.debdiff -- 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-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base Status in libseccomp package in Ubuntu: New Bug description: [Impact] snap-confine 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. [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. Any possible regressions may include applications now seeing correct system call resolution whereas previously this would have failed, and so perhaps previous failures (which were erroneous) will now be permitted. However, this was always permitted previously by the policy anyway but just denied due to this bug so it is not a true regression as such. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1876055/+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 1879234] Re: Xorg freeze
Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find. ** Information type changed from Private Security to Public -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1879234 Title: Xorg freeze Status in xorg package in Ubuntu: New Bug description: when i was my computer on and start blinking middle of screen please solve it. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 ProcVersionSignature: Ubuntu 5.3.0-51.44~18.04.2-generic 5.3.18 Uname: Linux 5.3.0-51-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.14 Architecture: amd64 CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Mon May 18 10:24:02 2020 DistUpgraded: Fresh install DistroCodename: bionic DistroVariant: ubuntu GraphicsCard: Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] [1002:15dd] (rev c8) (prog-if 00 [VGA controller]) Subsystem: Gigabyte Technology Co., Ltd Radeon RX Vega 11 [1458:d000] MachineType: Gigabyte Technology Co., Ltd. A320M-S2H ProcEnviron: LANGUAGE=en_IN:en PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_IN SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-51-generic root=UUID=38903ee5-fb7c-4faa-ac0c-0a499b16e531 ro quiet splash nomodeset vt.handoff=1 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/08/2018 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: F23 dmi.board.asset.tag: Default string dmi.board.name: A320M-S2H-CF dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: x.x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF23:bd08/08/2018:svnGigabyteTechnologyCo.,Ltd.:pnA320M-S2H:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnA320M-S2H-CF:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring: dmi.product.family: Default string dmi.product.name: A320M-S2H dmi.product.sku: Default string dmi.product.version: Default string dmi.sys.vendor: Gigabyte Technology Co., Ltd. version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.99-1ubuntu1~18.04.2 version.libgl1-mesa-dri: libgl1-mesa-dri 19.2.8-0ubuntu0~18.04.3 version.libgl1-mesa-glx: libgl1-mesa-glx 19.2.8-0ubuntu0~18.04.3 version.xserver-xorg-core: xserver-xorg-core N/A version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1879234/+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 1879211] Re: Charging my cellphone through usb breaks internet connection.
This doesn't seem like a security issue to me - I believe this is the default behaviour when using network manager for tethering - it will route traffic via the tethered device. I am reassigning this against network-manager which is likely doing the route setup. ** Information type changed from Private Security to Public ** Package changed: iptables (Ubuntu) => network-manager (Ubuntu) -- 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/1879211 Title: Charging my cellphone through usb breaks internet connection. Status in network-manager package in Ubuntu: New Bug description: I don't know what package is responsible for this. I entered iptables because the ip command was not recognized as a package. I use the ip route to debug internet problems. Here it is before plugging my cellphone through usb: #ip route default via 192.168.0.1 dev wlp2s0 proto dhcp metric 600 25.0.0.0/8 dev ham0 proto kernel scope link src 25.69.248.65 169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown 192.168.0.0/24 dev wlp2s0 proto kernel scope link src 192.168.0.51 metric 600 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown Here it is after I plug my cellphone #ip route default via 192.168.42.129 dev enp0s20f0u1 proto dhcp metric 100 default via 192.168.0.1 dev wlp2s0 proto dhcp metric 600 25.0.0.0/8 dev ham0 proto kernel scope link src 25.69.248.65 169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown 192.168.0.0/24 dev wlp2s0 proto kernel scope link src 192.168.0.51 metric 600 192.168.42.0/24 dev enp0s20f0u1 proto kernel scope link src 192.168.42.114 metric 100 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown So my computer is trying to access all ips using my cellphone as a router, which of course fails. the command "sudo ip route del default" followed by "sudo ip route add default via 192.168.0.1 dev wlp2s0" restores my connection. Thank you for your attention. I'm available to answer any questions and fix this bug. Reporting this bug was already effort diverted from my other tasks, so let's make this count no matter how deep it cuts. P.S: I went ahead and marked this bug as a security vulnerability because I can think of ways this can be exploited, especially if the cellphone can trigger the bug and route traffic so that the user doesn't suspect it. If you feel the security impact is small and that there are other more important security issues, feel free to unmark it and we can deal with it's usability impact, which is probably more impactful. Regards, Tomás. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: iptables 1.6.1-2ubuntu2 ProcVersionSignature: Ubuntu 4.15.0-99.100-generic 4.15.18 Uname: Linux 4.15.0-99-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.14 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Sun May 17 22:59:02 2020 InstallationDate: Installed on 2019-02-08 (464 days ago) InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) SourcePackage: iptables UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1879211/+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 1879211] Re: Charging my cellphone through usb breaks internet connection.
One more thing - I expect your phone has USB Tethering enabled - and so presents itself as an rndis USB/ethernet device - and then network manager uses this as a preferred interface to route traffic through rather than the wireless interface. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1879211 Title: Charging my cellphone through usb breaks internet connection. Status in network-manager package in Ubuntu: New Bug description: I don't know what package is responsible for this. I entered iptables because the ip command was not recognized as a package. I use the ip route to debug internet problems. Here it is before plugging my cellphone through usb: #ip route default via 192.168.0.1 dev wlp2s0 proto dhcp metric 600 25.0.0.0/8 dev ham0 proto kernel scope link src 25.69.248.65 169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown 192.168.0.0/24 dev wlp2s0 proto kernel scope link src 192.168.0.51 metric 600 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown Here it is after I plug my cellphone #ip route default via 192.168.42.129 dev enp0s20f0u1 proto dhcp metric 100 default via 192.168.0.1 dev wlp2s0 proto dhcp metric 600 25.0.0.0/8 dev ham0 proto kernel scope link src 25.69.248.65 169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown 192.168.0.0/24 dev wlp2s0 proto kernel scope link src 192.168.0.51 metric 600 192.168.42.0/24 dev enp0s20f0u1 proto kernel scope link src 192.168.42.114 metric 100 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown So my computer is trying to access all ips using my cellphone as a router, which of course fails. the command "sudo ip route del default" followed by "sudo ip route add default via 192.168.0.1 dev wlp2s0" restores my connection. Thank you for your attention. I'm available to answer any questions and fix this bug. Reporting this bug was already effort diverted from my other tasks, so let's make this count no matter how deep it cuts. P.S: I went ahead and marked this bug as a security vulnerability because I can think of ways this can be exploited, especially if the cellphone can trigger the bug and route traffic so that the user doesn't suspect it. If you feel the security impact is small and that there are other more important security issues, feel free to unmark it and we can deal with it's usability impact, which is probably more impactful. Regards, Tomás. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: iptables 1.6.1-2ubuntu2 ProcVersionSignature: Ubuntu 4.15.0-99.100-generic 4.15.18 Uname: Linux 4.15.0-99-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.14 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Sun May 17 22:59:02 2020 InstallationDate: Installed on 2019-02-08 (464 days ago) InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) SourcePackage: iptables UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1879211/+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 1879159] Re: Boot Problem
Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find. ** Information type changed from Private Security to Public -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1879159 Title: Boot Problem Status in xorg package in Ubuntu: New Bug description: It shows graphics problem during booting and unable to operate mouse. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: xorg 1:7.7+13ubuntu3.1 ProcVersionSignature: Ubuntu 4.4.0-179.209-generic 4.4.219 Uname: Linux 4.4.0-179-generic i686 .tmp.unity_support_test.0: ApportVersion: 2.20.1-0ubuntu2.23 Architecture: i386 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: compiz CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0' CompositorUnredirectFSW: true Date: Sun May 17 13:19:12 2020 DistUpgraded: 2020-03-29 23:06:17,899 DEBUG /openCache(), new cache size 56855 DistroCodename: xenial DistroVariant: ubuntu ExtraDebuggingInterest: Yes, including running git bisection searches GraphicsCard: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Dell 3rd Gen Core processor Graphics Controller [1028:0555] InstallationDate: Installed on 2020-03-24 (54 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release i386 (20140417) MachineType: Dell Inc. Inspiron 3520 ProcEnviron: LANGUAGE=en_IN:en PATH=(custom, no user) LANG=en_IN SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-179-generic root=UUID=2e048bbe-fc79-442e-ae8d-aac97ebb2938 ro quiet splash vt.handoff=7 init=/sbin/upstart SourcePackage: xorg UpgradeStatus: Upgraded to xenial on 2020-03-29 (48 days ago) dmi.bios.date: 05/31/2018 dmi.bios.vendor: Dell Inc. dmi.bios.version: A12 dmi.board.name: 0486TW dmi.board.vendor: Dell Inc. dmi.board.version: A12 dmi.chassis.type: 8 dmi.chassis.vendor: Dell Inc. dmi.chassis.version: Not Specified dmi.modalias: dmi:bvnDellInc.:bvrA12:bd05/31/2018:svnDellInc.:pnInspiron3520:pvrNotSpecified:rvnDellInc.:rn0486TW:rvrA12:cvnDellInc.:ct8:cvrNotSpecified: dmi.product.name: Inspiron 3520 dmi.product.version: Not Specified dmi.sys.vendor: Dell Inc. version.compiz: compiz 1:0.9.12.3+16.04.20180221-0ubuntu1 version.libdrm2: libdrm2 2.4.91-2~16.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 18.0.5-0ubuntu0~16.04.1 version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A version.libgl1-mesa-glx: libgl1-mesa-glx 18.0.5-0ubuntu0~16.04.1 version.xserver-xorg-core: xserver-xorg-core 2:1.18.4-0ubuntu0.8 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.1-1ubuntu2 version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.7.0-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20160325-1ubuntu1.2 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.12-1build2 xserver.bootTime: Sun May 17 13:15:51 2020 xserver.configfile: default xserver.errors: xserver.logfile: /var/log/Xorg.0.log xserver.outputs: product id 21569 vendor SEC xserver.version: 2:1.18.4-0ubuntu0.8 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1879159/+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-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base
** Description changed: [Impact] - snap-confine 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 + 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. + 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 resolution whereas previously this would have failed, and so perhaps previous failures (which were erroneous) will now be permitted. However, this was always permitted previously by the policy anyway but just denied due to this bug so it is not a true regression as such. + + + I have prepared these updates in the ubuntu-security-proposed PPA - could the SRU team could please review these in lieu of attached
[Touch-packages] [Bug 1876055] Re: SRU: Backport 2.4.3-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base
** Also affects: libseccomp (Ubuntu Groovy) Importance: Medium Status: New ** Also affects: libseccomp (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: libseccomp (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: libseccomp (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: libseccomp (Ubuntu Focal) Importance: Undecided Status: New -- 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-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base 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 Eoan: New Status in libseccomp source package in Focal: New Status in libseccomp source package in Groovy: New 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
[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
** Summary changed: - SRU: Backport 2.4.3-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base + SRU: Backport 2.4.3-1ubuntu3 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base and test suite robustness -- 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: Confirmed Status in libseccomp source package in Bionic: Confirmed Status in libseccomp source package in Eoan: Confirmed Status in libseccomp source package in Focal: Confirmed 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 t
[Touch-packages] [Bug 1862112] Re: apparmor prevents DHCP from starting with IPoIB interface
Can you try adding the following to /etc/apparmor.d/local/usr.sbin.dhcpd: network packet dgram, And then running sudo apparmor_parser -rT /etc/apparmor.d/usr.sbin.dhcpd And see if restart dhcpd then works? -- 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/1862112 Title: apparmor prevents DHCP from starting with IPoIB interface Status in isc-dhcp package in Ubuntu: New Bug description: # lsb_release -rd Description:Ubuntu Focal Fossa (development branch) Release:20.04 # apt-cache policy isc-dhcp-server isc-dhcp-server: Installed: 4.4.1-2ubuntu6 Candidate: 4.4.1-2ubuntu6 Version table: *** 4.4.1-2ubuntu6 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status I expect isc-dhcp-server to start. It does not because apparmor blocks something related to having an ib_ipoib interface present. I have infiniband interfaces using IPoIB. This prevents DHCP from starting because apparmor DENIES something. ip addr list: 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp3s0f0: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 1c:c1:de:e6:b4:08 brd ff:ff:ff:ff:ff:ff inet 130.166.47.2/24 brd 130.166.47.255 scope global enp3s0f0 valid_lft forever preferred_lft forever inet 130.166.47.1/24 brd 130.166.47.255 scope global secondary enp3s0f0 valid_lft forever preferred_lft forever inet6 fe80::1ec1:deff:fee6:b408/64 scope link valid_lft forever preferred_lft forever 3: enp3s0f1: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 1c:c1:de:e6:b4:0a brd ff:ff:ff:ff:ff:ff inet 10.47.0.2/16 brd 10.47.255.255 scope global enp3s0f1 valid_lft forever preferred_lft forever inet6 fe80::1ec1:deff:fee6:b40a/64 scope link valid_lft forever preferred_lft forever 4: enp4s0f0: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 1c:c1:de:e6:b4:00 brd ff:ff:ff:ff:ff:ff inet 10.0.47.2/24 brd 10.0.47.255 scope global enp4s0f0 valid_lft forever preferred_lft forever inet6 fe80::1ec1:deff:fee6:b400/64 scope link valid_lft forever preferred_lft forever 5: enp4s0f1: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 1c:c1:de:e6:b4:02 brd ff:ff:ff:ff:ff:ff inet 130.166.240.19/29 brd 130.166.240.23 scope global enp4s0f1 valid_lft forever preferred_lft forever inet 130.166.240.18/29 brd 130.166.240.23 scope global secondary enp4s0f1 valid_lft forever preferred_lft forever inet6 fe80::1ec1:deff:fee6:b402/64 scope link valid_lft forever preferred_lft forever 8: ibs1: mtu 2044 qdisc fq_codel state UP group default qlen 256 link/infiniband 80:00:02:0a:fe:80:00:00:00:00:00:00:00:02:c9:03:00:0f:45:ef brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff inet 192.168.47.2/24 brd 192.168.47.255 scope global ibs1 valid_lft forever preferred_lft forever inet6 fe80::202:c903:f:45ef/64 scope link valid_lft forever preferred_lft forever 9: ibs1d1: mtu 4092 qdisc noop state DOWN group default qlen 256 link/infiniband 80:00:02:0b:fe:80:00:00:00:00:00:00:00:02:c9:03:00:0f:45:f0 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff # service isc-dhcp-server start # tail /var/log/syslog Feb 6 05:26:50 firewalla systemd[1]: Started ISC DHCP IPv4 server. Feb 6 05:26:50 firewalla dhcpd[2513]: Internet Systems Consortium DHCP Server 4.4.1 Feb 6 05:26:50 firewalla sh[2513]: Internet Systems Consortium DHCP Server 4.4.1 Feb 6 05:26:50 firewalla sh[2513]: Copyright 2004-2018 Internet Systems Consortium. Feb 6 05:26:50 firewalla sh[2513]: All rights reserved. Feb 6 05:26:50 firewalla sh[2513]: For info, please visit https://www.isc.org/software/dhcp/ Feb 6 05:26:50 firewalla dhcpd[2513]: Copyright 2004-2018 Internet Systems Consortium. Feb 6 05:26:50 firewalla dhcpd[2513]: All rights reserved. Feb 6 05:26:50 firewalla dhcpd[2513]: For info, please visit https://www.isc.org/software/dhcp/ Feb 6 05:26:50 firewalla kernel: [ 1098.134784] audit: type=1400 audit(1580966810.775:62): apparmor="DENIED" operation="open" profile="/usr/sbin/dhcpd" name="/proc/sys/net/ipv4/ip_local_port_range" pid=2513 comm="dhcpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Feb 6 05:26:50 firewalla kernel: [ 1098.134926] audit: type=1400 audit(1580966810.775:63): apparmor="DENIED" operation="open" profile="/usr/sbin/dhcpd" name="/proc/sys/net/ipv4/ip_local_port_
[Touch-packages] [Bug 1862717] [NEW] Automatic crash report bug reports opened in gedit rather than the browser
Public bug reported: If a crash report is triggered automatically (say from a program crash etc) then the Apport UI pops up asking whether to report this - if I choose to proceed, after about 30 seconds gedit pops up with a HTML document showing 'OpenID transaction in progress' - which is the login.launchpad.net openid page. Looking at the gedit document title this shows the URL which should have got loaded by firefox - and so it appears that gedit has been spawned instead of firefox to handle the xdg-open call to report the bug. >From journalctl I can see that it is root spawning this xdg-open call: Feb 11 13:06:24 slate sudo[266010]: root : TTY=unknown ; PWD=/root ; USER=amurray ; ENV=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus ; COMMAND=/usr/bin/xdg-open https://bugs.launchpad.net/ubuntu/+source /dleyna-core/+filebug/4bc4c494-4c77-11ea-b34a- 002481e7f48a?field.title=package+libdleyna- core-1.0-5+%28not+installed%29+failed+to+install%2Fupgrade%3A+trying+to+overwrite+%27%2Fusr%2Flib%2Fx86_64 -linux-gnu%2Flibdleyna-core-1.0.so.5.0.0%27%2C+which+is+also+in+package +libdleyna-core-1.0-3%3Aamd64+0.6.0-1 And so I wonder if it is something to do with root's configuration for preferred applications (or not...) This does not occur when running ubuntu-bug from a terminal (since I assume in this case, the xdg-open call ends up coming from the users' own session). ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: apport 2.20.11-0ubuntu16 ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8 Uname: Linux 5.4.0-12-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportLog: ApportVersion: 2.20.11-0ubuntu16 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Feb 11 13:34:42 2020 InstallationDate: Installed on 2019-11-18 (84 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) PackageArchitecture: all SourcePackage: apport UpgradeStatus: Upgraded to focal on 2020-01-22 (19 days ago) ** Affects: apport (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal ** Attachment added: "gedit with the crash report" https://bugs.launchpad.net/bugs/1862717/+attachment/5327200/+files/Screenshot%20from%202020-02-11%2013-42-40.png -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1862717 Title: Automatic crash report bug reports opened in gedit rather than the browser Status in apport package in Ubuntu: New Bug description: If a crash report is triggered automatically (say from a program crash etc) then the Apport UI pops up asking whether to report this - if I choose to proceed, after about 30 seconds gedit pops up with a HTML document showing 'OpenID transaction in progress' - which is the login.launchpad.net openid page. Looking at the gedit document title this shows the URL which should have got loaded by firefox - and so it appears that gedit has been spawned instead of firefox to handle the xdg-open call to report the bug. From journalctl I can see that it is root spawning this xdg-open call: Feb 11 13:06:24 slate sudo[266010]: root : TTY=unknown ; PWD=/root ; USER=amurray ; ENV=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus ; COMMAND=/usr/bin/xdg-open https://bugs.launchpad.net/ubuntu/+source /dleyna-core/+filebug/4bc4c494-4c77-11ea-b34a- 002481e7f48a?field.title=package+libdleyna- core-1.0-5+%28not+installed%29+failed+to+install%2Fupgrade%3A+trying+to+overwrite+%27%2Fusr%2Flib%2Fx86_64 -linux-gnu%2Flibdleyna- core-1.0.so.5.0.0%27%2C+which+is+also+in+package+libdleyna- core-1.0-3%3Aamd64+0.6.0-1 And so I wonder if it is something to do with root's configuration for preferred applications (or not...) This does not occur when running ubuntu-bug from a terminal (since I assume in this case, the xdg-open call ends up coming from the users' own session). ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: apport 2.20.11-0ubuntu16 ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8 Uname: Linux 5.4.0-12-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportLog: ApportVersion: 2.20.11-0ubuntu16 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Feb 11 13:34:42 2020 InstallationDate: Installed on 2019-11-18 (84 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) PackageArchitecture: all SourcePackage: apport UpgradeStatus: Upgraded to focal on 2020-01-22 (19 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1862717/+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 1862717] Re: Automatic crash report bug reports opened in gedit rather than the browser
Relevant parts from journalctl: Feb 11 13:03:53 slate systemd[6652]: Starting Notification regarding a crash report... Feb 11 13:03:53 slate update-notifier-crash[260823]: /usr/bin/whoopsie Feb 11 13:03:54 slate update-notifier-crash[260837]: /var/crash/libdleyna-core-1 Feb 11 13:04:19 slate systemd[6652]: update-notifier-crash.service: Succeeded. Feb 11 13:04:19 slate systemd[6652]: Started Notification regarding a crash report. Feb 11 13:05:51 slate polkitd(authority=local)[2853]: Operator of unix-session:2 successfully authenticated as unix-user:amurray to gain ONE-SHOT authorization for action com.ubuntu.apport.apport-gtk-root for unix-process:6652:3047 [/lib/systemd/systemd --user] (> Feb 11 13:05:51 slate pkexec[264867]: pam_unix(polkit-1:session): session opened for user root by (uid=1000) Feb 11 13:05:51 slate pkexec[264867]: amurray: Executing command [USER=root] [TTY=unknown] [CWD=/home/amurray] [COMMAND=/usr/share/apport/apport-gtk] Feb 11 13:05:51 slate systemd[6652]: Starting Notification regarding a crash report... Feb 11 13:05:51 slate update-notifier-crash[265049]: /usr/bin/whoopsie Feb 11 13:05:51 slate systemd[6652]: update-notifier-crash.service: Succeeded. Feb 11 13:05:51 slate systemd[6652]: Started Notification regarding a crash report. Feb 11 13:05:57 slate systemd[6652]: Starting Notification regarding a crash report... Feb 11 13:05:57 slate update-notifier-crash[265340]: /usr/bin/whoopsie Feb 11 13:05:58 slate systemd[6652]: update-notifier-crash.service: Succeeded. Feb 11 13:05:58 slate systemd[6652]: Started Notification regarding a crash report. Feb 11 13:06:13 slate systemd[6652]: Starting Notification regarding a crash report... Feb 11 13:06:13 slate update-notifier-crash[265816]: /usr/bin/whoopsie Feb 11 13:06:14 slate systemd[6652]: update-notifier-crash.service: Succeeded. Feb 11 13:06:14 slate systemd[6652]: Started Notification regarding a crash report. Feb 11 13:06:17 slate whoopsie[5815]: [13:06:17] Parsing /var/crash/libdleyna-core-1.0-5.0.crash. Feb 11 13:06:17 slate systemd[6652]: Starting Notification regarding a crash report... Feb 11 13:06:17 slate whoopsie[5815]: [13:06:17] Uploading /var/crash/libdleyna-core-1.0-5.0.crash. Feb 11 13:06:17 slate update-notifier-crash[265873]: /usr/bin/whoopsie Feb 11 13:06:17 slate systemd[6652]: update-notifier-crash.service: Succeeded. Feb 11 13:06:17 slate systemd[6652]: Started Notification regarding a crash report. Feb 11 13:06:20 slate whoopsie[5815]: [13:06:20] Sent; server replied with: No error Feb 11 13:06:20 slate whoopsie[5815]: [13:06:20] Response code: 200 Feb 11 13:06:20 slate whoopsie[5815]: [13:06:20] Reported OOPS ID 4948a47e-4c77-11ea-a966-fa163e983629 Feb 11 13:06:20 slate systemd[6652]: Starting Notification regarding a crash report... Feb 11 13:06:20 slate update-notifier-crash[265936]: /usr/bin/whoopsie Feb 11 13:06:20 slate systemd[6652]: update-notifier-crash.service: Succeeded. Feb 11 13:06:20 slate systemd[6652]: Started Notification regarding a crash report. Feb 11 13:06:24 slate sudo[266010]: root : TTY=unknown ; PWD=/root ; USER=amurray ; ENV=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus ; COMMAND=/usr/bin/xdg-open https://bugs.launchpad.net/ubuntu/+source/dleyna-core/+filebug/4bc4c494-4c77-11ea-b34a-00> Feb 11 13:06:24 slate sudo[266010]: pam_unix(sudo:session): session opened for user amurray by (uid=0) Feb 11 13:06:28 slate dbus-daemon[6678]: [session uid=1000 pid=6678] Activating service name='org.gnome.gedit' requested by ':1.258' (uid=1000 pid=266018 comm="gio open https://bugs.launchpad.net/ubuntu/+source"; label="unconfined") Feb 11 13:06:28 slate dbus-daemon[6678]: [session uid=1000 pid=6678] Successfully activated service 'org.gnome.gedit' Feb 11 13:06:31 slate gedit[266061]: can't init metadata tree /home/amurray/.local/share/gvfs-metadata/http:uri=https%3A%2F%2Fbugs.launchpad.net%2Fubuntu%2F+source%2Fdleyna-core%2F+filebug%2F4bc4c494-4c77-11ea-b34a-002481e7f48a%3Ffield.title%3Dpackage+libdleyna-c> Feb 11 13:06:31 slate sudo[266010]: pam_unix(sudo:session): session closed for user amurray -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1862717 Title: Automatic crash report bug reports opened in gedit rather than the browser Status in apport package in Ubuntu: New Bug description: If a crash report is triggered automatically (say from a program crash etc) then the Apport UI pops up asking whether to report this - if I choose to proceed, after about 30 seconds gedit pops up with a HTML document showing 'OpenID transaction in progress' - which is the login.launchpad.net openid page. Looking at the gedit document title this shows the URL which should have got loaded by firefox - and so it appears that gedit has been spawned instead of firefox to handle the xdg-open call to report the bug. From journalct
[Touch-packages] [Bug 1706770] Re: Lock screen can be bypassed when auto-login is enabled.
** 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 lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1706770 Title: Lock screen can be bypassed when auto-login is enabled. Status in Ubuntu MATE: Confirmed Status in lightdm package in Ubuntu: Confirmed Status in mate-session-manager package in Ubuntu: Confirmed Bug description: 16.04 LTS = Hi, My machine is set up with full-disk encryption, so it requires a password when I boot it up. Because of this I thought I would enable auto-login to avoid having to enter two passwords at boot. When I leave my computer for short periods of time, I lock it. I thought this was working fine for a long time, but I've discovered the lock screen is actually easily bypassable when auto-login is enabled. All one has to do is click "Switch User" on the lock screen, then press "Unlock" and the computer unlocks without prompting for a password. Perhaps this is just me being an idiot, but I thought this was secure until now. It seems like either unlocking should always require a password (otherwise what's the point of locking in the first place) or it should be made totally obvious that unlocking doesn't actually require a password (i.e. removing the password box from the lock screen when auto-login is enabled). Thanks, Chris To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-mate/+bug/1706770/+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 1867735] Re: Can't login after computer locks on idle
gnome-shell is responsible for the lock screen so reassigning to that ** Package changed: shadow (Ubuntu) => gnome-shell (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1867735 Title: Can't login after computer locks on idle Status in gnome-shell package in Ubuntu: New Bug description: After a leave my computer on idle and try to put my password to login the screen starts to blink whenever I click on the screen. The workaround I found is to click on the switch user button to log back in but some windows are closed on this process. Also when the screen is locked I'm able to see the windows running on the user profile without unlocking ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: login 1:4.8.1-1ubuntu3 ProcVersionSignature: Ubuntu 5.4.0-18.22-generic 5.4.24 Uname: Linux 5.4.0-18-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu20 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Mar 17 09:49:09 2020 InstallationDate: Installed on 2019-12-24 (83 days ago) InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64 (20190805) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: shadow UpgradeStatus: Upgraded to focal on 2020-03-15 (1 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1867735/+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 1867898] Re: package libaudit1:amd64 1:2.4.5-1ubuntu2 [modified: lib/x86_64-linux-gnu/libaudit.so.1.0.0 usr/share/doc/libaudit1/changelog.Debian.gz] failed to install/upgrade: pa
Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find. ** Information type changed from Private Security to Public -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to audit in Ubuntu. https://bugs.launchpad.net/bugs/1867898 Title: package libaudit1:amd64 1:2.4.5-1ubuntu2 [modified: lib/x86_64-linux- gnu/libaudit.so.1.0.0 usr/share/doc/libaudit1/changelog.Debian.gz] failed to install/upgrade: package libaudit1:amd64 is not ready for configuration cannot configure (current status 'half-installed') Status in audit package in Ubuntu: New Bug description: error while updating browser ProblemType: Package DistroRelease: Ubuntu 16.04 Package: libaudit1:amd64 1:2.4.5-1ubuntu2 [modified: lib/x86_64-linux-gnu/libaudit.so.1.0.0 usr/share/doc/libaudit1/changelog.Debian.gz] ProcVersionSignature: Ubuntu 4.10.0-42.46~16.04.1-generic 4.10.17 Uname: Linux 4.10.0-42-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.15 AptOrdering: libaudit1: Configure firefox: Install firefox: Configure NULL: ConfigurePending Architecture: amd64 Date: Wed Mar 18 09:51:52 2020 Dependencies: gcc-6-base 6.0.1-0ubuntu1 libaudit-common 1:2.4.5-1ubuntu2.1 libc6 2.23-0ubuntu11 libgcc1 1:6.0.1-0ubuntu1 DpkgTerminalLog: dpkg: error processing package libaudit1:amd64 (--configure): package libaudit1:amd64 is not ready for configuration cannot configure (current status 'half-installed') ErrorMessage: package libaudit1:amd64 is not ready for configuration cannot configure (current status 'half-installed') InstallationDate: Installed on 2017-07-18 (973 days ago) InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 (20170215.2) RelatedPackageVersions: dpkg 1.18.4ubuntu1.6 apt 1.2.32 SourcePackage: audit Title: package libaudit1:amd64 1:2.4.5-1ubuntu2 [modified: lib/x86_64-linux-gnu/libaudit.so.1.0.0 usr/share/doc/libaudit1/changelog.Debian.gz] failed to install/upgrade: package libaudit1:amd64 is not ready for configuration cannot configure (current status 'half-installed') UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/audit/+bug/1867898/+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] [NEW] SRU: Backport 2.4.3-1ubuntu1 from focal to eoan/bionic/xenial for newer syscalls for core20 base
Public bug reported: Placeholder to start preparing SRU for https://github.com/snapcore/core20/issues/48 ** Affects: libseccomp (Ubuntu) Importance: Undecided Status: New -- 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-1ubuntu1 from focal to eoan/bionic/xenial for newer syscalls for core20 base Status in libseccomp package in Ubuntu: New Bug description: Placeholder to start preparing SRU for https://github.com/snapcore/core20/issues/48 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1876055/+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 1550090] [NEW] linux-image-3.19.0-51-generic fails to boot to desktop under VMWare Player
Public bug reported: After updating my VMWare Player install of Ubuntu 14.04 amd64 to linux- image-3.19.0-51-generic it fails to boot - plymouth appears to hang during boot and so it never reaches the GDM login screen - also seems I am not alone: http://askubuntu.com/questions/738083/ubuntu-14-04-4-lts-hangs-on-boot-after-latest-dist-upgrade-in-vmware http://ubuntuforums.org/showthread.php?t=2314723 Booting from the previous kernel 3.19.0-49-generic works fine. ** Affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1550090 Title: linux-image-3.19.0-51-generic fails to boot to desktop under VMWare Player Status in initramfs-tools package in Ubuntu: New Bug description: After updating my VMWare Player install of Ubuntu 14.04 amd64 to linux-image-3.19.0-51-generic it fails to boot - plymouth appears to hang during boot and so it never reaches the GDM login screen - also seems I am not alone: http://askubuntu.com/questions/738083/ubuntu-14-04-4-lts-hangs-on-boot-after-latest-dist-upgrade-in-vmware http://ubuntuforums.org/showthread.php?t=2314723 Booting from the previous kernel 3.19.0-49-generic works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1550090/+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 2083435] Re: AppArmor 4.1.0-beta1 contains an ABI break for aa_log_record
I typod the magic LP bug reference in the changelog but this was upload to oracular earlier and just moved into -proposed: apparmor (4.1.0~beta1-0ubuntu3) oracular; urgency=medium * Add patch from upstream to fix unintentional ABI break (LP :#2083435) - d/p/u/fix-abi-break-record-for-aa-log-record.patch https://launchpad.net/ubuntu/+source/apparmor/4.1.0~beta1-0ubuntu3 ** Changed in: apparmor (Ubuntu Oracular) Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/2083435 Title: AppArmor 4.1.0-beta1 contains an ABI break for aa_log_record Status in AppArmor: New Status in apparmor package in Ubuntu: Fix Committed Status in apparmor source package in Oracular: Fix Committed Bug description: Commit 3c825eb001d33bb6f2480c4f78df03aee4c40396 in the Gitlab upstream adds a field called `execpath` to the `aa_log_record` struct. This field was added in the middle of the struct instead of the end, causing an ABI break in libapparmor without a corresponding major version number bump. This commit landed between v4.0.3 and v4.1.0-beta1, and unfortunately, Oracular currently packages v4.1.0-beta1. Thus, we need to land a bugfix patch to move the `execpath` field to the end of the struct ASAP to prevent an ABI break from making it into the Oracular release. The patch is attached below and is available as commit c86c87e8868c72e5ab2084b5bf783cd5ca800a9b in the Gitlab repo. To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/2083435/+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
