proposed-migration for cups-browsed 2.0.0-0ubuntu8

[Steve Langasek]

cups-browsed 2.0.0-0ubuntu8 on armhf segfaults on startup (detected via an autopkgtest), early enough that LD_DEBUG=all gives no output. A local no-change rebuild of 2.0.0-0ubuntu7 succeeded and the executable ran, so 8 was uploaded to try to fix this. But the executable somehow ONLY runs as ./debian/cups-browsed/usr/sbin/cups-browsed and segfaults when invoked as /usr/sbin/cups-browsed.

[Steve Langasek (vorlon)]

and the problem is with apparmor. `aa-disable /usr/sbin/cups-browsed` allows the program to run.

[Steve Langasek (vorlon)]

[1724567.629003] audit: type=1400 audit(1711133926.877:813): apparmor="DENIED" operation="file_mmap" class="file" namespace="root//lxd-noble-armhf_<var-snap-lxd-common-lxd>" profile="/usr/sbin/cups-browsed" name="/usr/sbin/cups-browsed" pid=876865 comm="cups-browsed" requested_mask="rm" denied_mask="rm" fsuid=1000110 ouid=1000000

[Steve Langasek (vorlon)]

Reproducible on amd64.

[6037055.006277] audit: type=1400 audit(1711335561.053:35916): apparmor="DENIED" operation="file_mmap" class="file" namespace="root//lxd-noble_<var-snap-lxd-common-lxd>" profile="/usr/sbin/cups-browsed" name="/usr/sbin/cups-browsed" pid=788055 comm="cups-browsed" requested_mask="r" denied_mask="r" fsuid=1000110 ouid=1000000

So this is a regression wrt cups-browsed running under apparmor in a container, and not specific to armhf.

[Steve Langasek (vorlon)]

cupsd 2.0.0-0ubuntu8 contains no sourceful changes vs 2.0.0-0ubuntu3 in noble release; these are no-change rebuilds only.

[John Johansen (jjohansen)]

Do we know if there is a difference in the kernel between the runs?

The 2.0.0.0~0ubuntu3 autopackage run log I was pointed at was on a
  Linux 5.4.0-170-generic #188-Ubuntu

Do we know what kernel that 2.0.0-0ubuntu7 is failing on? There was a change to when security checks were made in on the exec path, this particular denial makes me wonder if we are seeing an artifact of that here.

[Steve Langasek (vorlon)]

On Mon, Mar 25, 2024 at 05:16:57AM -0000, John Johansen wrote:
> Do we know if there is a difference in the kernel between the runs?

> The 2.0.0.0~0ubuntu3 autopackage run log I was pointed at was on a
> Linux 5.4.0-170-generic #188-Ubuntu

> Do we know what kernel that 2.0.0-0ubuntu7 is failing on? There was a
> change to when security checks were made in on the exec path, this
> particular denial makes me wonder if we are seeing an artifact of that
> here.

All logs on https://autopkgtest.ubuntu.com/packages/c/cups-browsed/noble/armhf
should include kernel information.

Latest 2.0.0-0ubuntu8 failure has:

211s autopkgtest [22:10:53]: testbed running kernel: Linux 5.15.0-101-generic #111-Ubuntu SMP Wed Mar 6 18:01:01 UTC 2024

Last successful 2.0.0-0ubuntu3 log has:

349s autopkgtest [18:43:33]: testbed running kernel: Linux 5.4.0-170-generic #188-Ubuntu SMP Wed Jan 10 09:51:10 UTC 2024

But that was a retry of the release version of the package AFTER things
started failing;
https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/armhf/c/cups-browsed/20240322_173402_07be9@/log.gz
is earlier and has:

351s autopkgtest [17:30:50]: testbed running kernel: Linux 5.4.0-170-generic #188-Ubuntu SMP Wed Jan 10 09:51:10 UTC 2024

so it's not a kernel difference.

It appears to be a genuine change in the binaries when built with new
toolchain that causes them to have a new mmap that wasn't there before?

If I aa-enforce and run strace, I see:

execve("/usr/sbin/cups-browsed", ["cups-browsed"], 0xffa82a54 /* 12 vars */) = -1 EACCES (Permission denied)

so this failure happens before we even reach the executable?

[John Johansen (jjohansen)]

So what I think is going on from a first pass look at this is that

We are seeing a change in kernel behavior around exec. The 6.8 has a known change here, that doesn't normally trigger because unconfined is delegating access into the profile. However in the lxd case, unconfined can is not delegating access it the profile needs access to the application.

the accompanying patch should fix the issue, and does not actually grant anymore permission that was already required, it was just being delegated in by unconfined.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "apparmor-add-execmap.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Łukasz Zemczak (sil2100)]

I'll take care of the sponsoring.

[Łukasz Zemczak (sil2100)]

Sponsored!

[Steve Langasek (vorlon)]

Thanks! Since this issue was seen only with the package in -proposed, I'm closing this bug.

There are other unrelated test failures now blocking the build on armhf. I will open a separate bug for these.

[Steve Langasek (vorlon)]

privoxy rebuild fails in containers with the same issue.

[Georgia Garcia (georgiag)]

The fix is similar for privoxy. I attached the debdiff that fixes it.

[Georgia Garcia (georgiag)]

Ah, sorry, Łukasz. I didn't see you were working on it.

[Launchpad Janitor (janitor)]

This bug was fixed in the package privoxy - 3.0.34-3ubuntu1

---------------
privoxy (3.0.34-3ubuntu1) noble; urgency=medium

  * debian/apparmor/usr.sbin.privoxy: attempt on fixing the denial on
    containers (LP: #2058866).

 -- Łukasz 'sil2100' Zemczak <email address hidden> Tue, 26 Mar 2024 17:16:43 +0100