[SRU] Add multiarch lines for each architecture we want to support in our apparmor profiles.

[Scarlett Gately Moore]

[ Impact ]

 * Crash on non amd64 architectures.

 * This fixes the crash.

 * Implement a less restrictive apparmor profile, following what all the other applications did.

[ Test Plan ]

 * install application in noble. try to launch on arm architecture.

[ Where problems could occur ]

 * None that I can think of.

[ Other Info ]

 * This fixes (LP: #2064492)

[Launchpad Janitor (janitor)]

This bug was fixed in the package plasma-welcome - 5.27.11-0ubuntu4

---------------
plasma-welcome (5.27.11-0ubuntu4) oracular; urgency=medium

  * Use less restrictive apparmor, folling other applications. (LP: #2065915)

 -- Scarlett Moore <email address hidden> Mon, 08 Jul 2024 19:26:02 +0100

[Robie Basak (racb)]

Thank you for working on this. I'm not doing my SRU shift but was surprised to see so many uploads appear in the SRU queue together so paused to take a look.

It looks like you're removing AppArmor confinement wholesale for a large number of packages, which I think requires exceptional justification in an SRU but I don't see this provided anywhere.

I would expect the minimal fix appropriate to fix the SRU to be to fix the specific multiarch path that is described as the underlying issue in bug 2064492. I see that was done initially in Oracular (eg. https://launchpad.net/ubuntu/+source/cantor/4:23.08.5-0ubuntu5) but then further changed again to drop confinement altogether (eg. https://launchpad.net/ubuntu/+source/cantor/4:23.08.5-0ubuntu6). Please could you explain why the former is (presumably) unsuitable?

Separately, we usually present SRUs as fixing the actual bug they're fixing, rather than creating a separate bug. So I'd have expected only bug 2064492 without this bug 2065915 being created. It's not clear to me what is separate to track here. See "Do not create a meta-bug" in step 1 of https://wiki.ubuntu.com/StableReleaseUpdates#Procedure. But let's focus on the real question and not worry about that for now.

[Launchpad Janitor (janitor)]

This bug was fixed in the package falkon - 24.05.1-1ubuntu2

---------------
falkon (24.05.1-1ubuntu2) oracular; urgency=medium

  * Add missing files.

 -- Scarlett Moore <email address hidden> Mon, 08 Jul 2024 09:08:41 -0700

[KDE (kde-community)]

Hi Robie,
Sorry I am a bit new on SRUs, so I am guessing I just should have rename the original bug to SRU and put the SRU info on that bug? As for the complete change rather than just the multiarch, it was due to the packages still didn't work, so I went back to the original apparmor mega bug and looked at what you canonical folks did for the gnome packages and this was the result. If this was not the correct approach then I will have to investigate further... thanks for your time.

[Scarlett Gately Moore (scarlettmoore)]

Also, what is exceptional justification. I can't find it in the docs.

[Robie Basak (racb)]

Thanks. Could you link directly to the uploads whose pattern you're
following please?

[Robie Basak (racb)]

On Tue, Jul 09, 2024 at 11:32:33AM -0000, Scarlett Gately Moore wrote:
> Also, what is exceptional justification. I can't find it in the docs.

The docs say that SRUs should be minimal. Search for "this tends to be
well-correlated with minimising the size of those changes" in
https://wiki.ubuntu.com/StableReleaseUpdates. I accept that the
documentation could be clearer and we are working on that, but the
current documentation does state this.

Turning off confinement entirely seems like much more than the required
minimal change to fix the bug. Since this doesn't appear to be following
our documented expectations, that's why I say that it needs exceptional
justification. Alternatively I'd like to see uploads that do appear to
meet those expectations.

[Scarlett Gately Moore (scarlettmoore)]

Hi Robie,
I understand now and will improve my future SRUs. I apologize for this.

I found this example of my profiles here https://git.launchpad.net/apparmor/tree/profiles/apparmor.d/

Therre are tons of profiles using this minimal approach, so I thought it would be ok for us to also use this approach.

Here is just one example: https://git.launchpad.net/apparmor/tree/profiles/apparmor.d/epiphany

There are 91 in total that use this profile.

Thanks for your time.
Scarlett

[Rik Mills (rikmills)]

91 is just what ships with the actual apparmor package. There may be more I assume.

In apparmor:

1password
Discord
MongoDB_Compass
QtWebEngineProcess
balena-etcher
brave
buildah
busybox
cam
ch-checkns
ch-run
chrome
code
crun
devhelp
element-desktop
epiphany
evolution
firefox
flatpak
foliate
geary
github-desktop
goldendict
ipa_verify
kchmviewer
keybase
lc-compliance
libcamerify
linux-sandbox
loupe
lxc-attach
lxc-create
lxc-destroy
lxc-execute
lxc-stop
lxc-unshare
lxc-usernsexecprofile
lxc-usernsexec
mmdebstrap
msedge
nautilus
notepadqq
obsidian
opam
opera
pageedit
podman
polypane
privacybrowser
qcam
qmapshack
qutebrowser
rootlesskit
rpm
rssguard
runc
sbuild
sbuild-abort
sbuild-adduser
sbuild-apt
sbuild-checkpackages
sbuild-clean
sbuild-createchroot
sbuild-destroychroot
sbuild-distupgrade
sbuild-hold
sbuild-shell
sbuild-unhold
sbuild-update
sbuild-upgrade
scide
signal-desktop
slack
slirp4netns
steam
stress-ng
surfshark
systemd-coredump
thunderbird
toybox
trinity
tup
tuxedo-control-center
userbindmount
uwsgi-core
vdens
virtiofsd
vivaldi-bin
vpnns
wike
wpcom

[Robie Basak (racb)]

Thanks. The profiles there are a bit different though - IIUC, they're there so that people who wish to opt-in to applying AppArmor profiles have a library to easily consult and use. There's a complication though which is that due to a change in 24.04 it's now required to explicitly enable "userns" so we need a bunch of profiles for those AIUI. I'm not familiar with how that fits in with the apparmor-profiles package, which I believe is still optional.

I believe it does make sense for packaging to ship a profile with "userns" where required so that the package works by default, and that's what I see those profiles doing and what you're now doing for these packages in Oracular. Up to there, everything seems correct.

Using "cantor" as an example, it looks like you added specific confinement for AppArmor profiles prior to the release of 24.04 though. To then turn off confinement in an update in 24.04 would be a regression from the user's perspective - going from confined (more secure) to unconfined (less secure) - contrary to typical user expectations of what a stable release means.

On the other hand it doesn't seem appropriate to mandate that you must now rewrite all the profiles you added so that they work and leave the package broken if you cannot.

If I'm missing something in my understanding above, please correct me!

I'm open to suggestions on how to resolve this dilemma, but I would like to explore further the possibility of fixing the existing profiles rather than removing confinement. You said that the "packages still didn't work". Maybe we can find somebody to help with that?

[KDE (kde-community)]

Hi Robie,
I followed https://ubuntu.com/server/docs/apparmor#:~:text=Also%2C%20replace%20/path/to,process%20is%20allowed%20to%20use. in creating my initial profiles. They worked great on AMD and then I presented the arm bug in which I found I had hard coded the multiarch path. Oops. So I thought ok, easy fix, just add the @mulitarch, right? Well now, none of my packages worked, ok, so maybe I have to add the include. Still didn't work. I am most certainly open to help. I admit I took the easy path with copying what so many packages did. If someone can help with the original multiarch problem, I am more than happy to continue with my original correct way to do apparmor profiles.
Scarlett

[Scarlett Gately Moore (scarlettmoore)]

I just noticed plasmashell is also hard coded! https://git.launchpad.net/apparmor/tree/profiles/apparmor.d/plasmashell I did not write this profile.
We have complaints that dbus is being denied.
There is so much more going on here. I am looking at the include problem that seems to be at the root of my original multiarch issue.

[Georgia Garcia (georgiag)]

As per the discussion in https://irclogs.ubuntu.com/2024/07/09/%23ubuntu-security.txt
The recommendation from the security team is to not revert to the "flags=(unconfined)" profile if the profile is already confined. That means that we should only fix the multiarch issue.

Scarlett, you're right, just adding the variable @{multiarch} directly does not work in this case, because due to how the parser is currently implemented, @{multiarch} translates to *-linux-gnu* and the wildcard makes it conflict with the "/** pux," rule. That's the reason that it's hard coded in the plasmashell profile as well. We are currently working on fixing it in the parser but it's not available right now.

So for this case, we would have to add the other arch hard coded too. Something like the following diff, for every architecture we want to support.

@@ -18,6 +18,7 @@
   ptrace,

   /usr/lib/x86_64-linux-gnu/qt5/libexec/QtWebEngineProcess cx -> &plasmashell//QtWebEngineProcess,
+ /usr/lib/aarch64-linux-gnu/qt5/libexec/QtWebEngineProcess cx -> &plasmashell//QtWebEngineProcess,
   /** pux,
   /{,**} mrwlk,

Regarding dbus being denied, could you point those reports my way? I'm more than happy to help

[Scarlett Gately Moore (scarlettmoore)]

Hi Georgia,
Thanks for your help.
As for the report, sadly it was in IRC. Here is what I have.

<Jozo> dbus-daemon[2511]: apparmor="DENIED" operation="dbus_method_call" bus="session" path="/org/mpris/MediaPlayer2" interface="org.freedesktop.DBus.Properties" member="GetAll" name=":1.4088" mask="receive" pid=3512860 label="snap.spotify.spotify" peer_pid=2045540 peer_label="plasmashell"

This was while trying to use spotify snap.

Scarlett

[Georgia Garcia (georgiag)]

Hi Scarlett,

No worries, that log should be enough to understand what's going on. That is a bug in the snapd interface because the AppArmor policy specified the peer_label as unconfined, but that's no longer the case for plasmashell. I'll reach out to the snapd team and report the issue. https://bugs.launchpad.net/snapd/+bug/2072762
Thank you!

[Robie Basak (racb)]

Further to comment 13 I agreed with Scarlett to reject the current uploads in the queue as they will need to be replaced.

[Georgia Garcia (georgiag)]

As I understand these changes are only waiting to be sponsored to proposed, correct?

[Scarlett Gately Moore (scarlettmoore)]

Yes, they need to go through the verification stage.
Scarlett