[SRU] - fixes for apparmor on noble

Bug #2064672 reported by Georgia Garcia
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
apparmor (Ubuntu)
In Progress
Undecided
Unassigned

Bug Description

[ Impact ]

This SRU has several fixes:

add unconfined profile for tuxedo-control-center (Bug 2046844)
fix issues appointed by coverity
fix samba profile (https://gitlab.com/apparmor/apparmor/-/issues/386)
fix redefinition of _ which caused an issue with translation, failing aa-enforce (https://gitlab.com/apparmor/apparmor/-/issues/387)
add mount test for CVE-2016-1585 (Bug 1597017 and Bug 2023814)
add network inet mediation documentation to apparmor.d
fix inet conditionals to only generate rules for inet family (https://gitlab.com/apparmor/apparmor/-/issues/384)
add unconfined wike profile (Bug 2060810)
add unconfined foliate profile (Bug 2060767)
fix chromium_browser profile (https://gitlab.com/apparmor/apparmor/-/merge_requests/1208)
add profiles for Transmission family of Bittorrent clients
add profile for unshare utility (Bug 2046844)
add profile for bwrap utility (Bug 2046844)
fix unconfined firefox profile to support mozilla.org download (Bug 2056297)
fix getattr and setattr perm mapping on mqueue rules (https://gitlab.com/apparmor/apparmor/-/issues/377 and https://gitlab.com/apparmor/apparmor/-/issues/378)
fix inet tests (https://gitlab.com/apparmor/apparmor/-/issues/376)
fix sshd profile (Bug 2060100)
fix apparmor tools to allow mount destination globbing (https://gitlab.com/apparmor/apparmor/-/issues/381)
fix firefox profile (https://gitlab.com/apparmor/apparmor/-/issues/380)
move pam-related permissions to abstractions/authentication (https://bugzilla.opensuse.org/show_bug.cgi?id=1220032)
fix condition in policydb serialization to only encode xtable if kernel_supports_permstable32
relax mount rules in utils to fix use of virtiofs and other file-system types

[ Test Plan ]

This has been extensively tested via the AppArmor regression test
script in the QA Regression Testing repo:
https://git.launchpad.net/qa-regression-testing/tree/scripts/test-apparmor.py

This script runs various tests against the installed apparmor
package, as well as building and running the various upstream
regression and other test suites against this installed package:
  - https://gitlab.com/apparmor/apparmor/-/tree/master/tests/regression/apparmor?ref_type=heads
  - https://gitlab.com/apparmor/apparmor/-/tree/master/utils/test?ref_type=heads
  - https://gitlab.com/apparmor/apparmor/-/tree/master/parser/tst?ref_type=heads
  - https://gitlab.com/apparmor/apparmor/-/tree/master/libraries/libapparmor/testsuite?ref_type=heads

The final test output was:

----------------------------------------------------------------------
Ran 62 tests in 1989.948s

OK (skipped=4)

georgia@sec-noble-amd64:~$ apt policy apparmor
apparmor:
  Installed: 4.0.1-0ubuntu0.24.04.2
  Candidate: 4.0.1-0ubuntu0.24.04.2

Run additional tests:

1. Install wike and make sure the wike window opens when executed:
$ sudo apt install wike
$ wike

2. Install foliate, download test epub and make sure it opens as expected:
$ sudo apt install foliate
$ wget https://github.com/daisy/epub-accessibility-tests/releases/download/fundamental-2.0/Fundamental-Accessibility-Tests-Basic-Functionality-v2.0.0.epub
$ foliate Fundamental-Accessibility-Tests-Basic-Functionality-v2.0.0.epub

3. Install transmission and make sure it starts properly:
$ sudo apt install transmission
$ transmission-gtk

4. bwrap profile tests:
- Install setzer and check if it opens as expected:
$ sudo apt install setzer
$ setzer
- Check if flatpak option --unshare=network works, the Recipes app window should open:
$ sudo apt install flatpak
$ flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
$ flatpak install flathub org.gnome.Recipes
$ flatpak run --unshare=network org.gnome.Recipes

[ Where problems could occur ]

There could still be more applications affected by the
restriction of the creation of unpriviliged user namespaces. They
might require the creation of new unconfined profiles which could
be mitigated in a later SRU.

[ Other Info ]

The SRU is available in:

https://launchpad.net/~georgiag/+archive/ubuntu/4.0.1-0ubuntu0.24.04.2

description: updated
description: updated
description: updated
description: updated
description: updated
description: updated
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in apparmor (Ubuntu):
status: New → Confirmed
Revision history for this message
Alex Murray (alexmurray) wrote (last edit ):

I have just uploaded apparmor 4.0.1-0ubuntu0.24.04.1 from georgiag's PPA to noble - it is sitting in the unapproved queue.

Changed in apparmor (Ubuntu):
status: Confirmed → In Progress
Revision history for this message
Samuel Moelius (smoelius) wrote (last edit ):

Please forgive me as I am unfamiliar with Ubuntu's release process.

What are the next steps to releasing this fix? And how soon could it appear in the normal distribution?

Revision history for this message
John Johansen (jjohansen) wrote :

@smoelius:

If you are interested in learning more of the processes, you can read about it at https://wiki.ubuntu.com/StableReleaseUpdates

To summarize the upload is at step 4 of the procedures. It has been uploaded but has not been promoted to the -proposed pocket. Once it has been accepted it will be in the -proposed pocket for a minimum of 7 days, the absolute earliest this SRU could land in updates is mid next week, but it will likely take a little longer.

It is available earlier either through the ppa (https://launchpad.net/~apparmor-dev/+archive/ubuntu/apparmor-sru), or the -proposed pocket (user opt in by enabling proposed) once promoted.

Revision history for this message
Samuel Moelius (smoelius) wrote :

@jjohansen Thank you very much for your detailed explanation!

Revision history for this message
Simon McVittie (smcv) wrote :

> add profile for bwrap utility

Please check that this doesn't make `flatpak run --unshare=network $APP_ID` regress.

Explanation:

Some Flatpak apps (the ones that have no legitimate reason to use networking) have `--unshare=network` by default, as a way to prevent them from contacting the internet if they are malicious or compromised. This sandboxing feature requires bwrap to use CAP_NET_ADMIN to bring up a loopback device inside the new network namespace, before it drops privileges and executes the actual sandboxed code. Otherwise, there would be no `lo` device and no 127.0.0.1 or ::1, breaking apps' reasonable expectations.

Many apps *normally* allow networking, but they can all be run with `--unshare=network` to force the no-network code path, for example `flatpak run --unshare=network org.gnome.Recipes`. Of course, some or all features of the app will not work when run like this, but it should at least start.

I'm hoping that either the new bwrap profile allows this, or the flatpak profile (previously added) takes precedence and allows CAP_NET_ADMIN to be used (briefly!) during the switch from the TCB to the sandboxed environment.

Revision history for this message
Georgia Garcia (georgiag) wrote :

Hi Simon,

The use of --unshare=network does not cause a regression with the bwrap profile.
This is the full profile: https://gitlab.com/apparmor/apparmor/-/blob/aa74b9b12d9ed55909489403a0c2514b9ea6a95f/profiles/apparmor/profiles/extras/bwrap-userns-restrict

If you look at the bwrap profile itself, you can see that it allows the use of all capabilities, but that on execs, it transitions to a profile that does not allow capabilities. That's bwrap can, briefly, use CAP_NET_ADMIN.

profile bwrap /usr/bin/bwrap ... {
  allow capability,
  ...
  allow px /** -> bwrap//&unpriv_bwrap,
}

To be clear, I tested `flatpak run --unshare=network org.gnome.Recipes` specifically and it worked as expected.

Revision history for this message
John Johansen (jjohansen) wrote :

It shouldn't but we do need to make sure it works.

Previously flatpak was getting around the bwrap restriction by using the flatpak unconfined profile. But the unconfined profile uses pix which means it will now use the bwrap profile, when calling bwrap.

If this does cause breakage we will need to move flatpak to using just ix when calling bwrap.

@smcv: do you have a specific app in mind to test.

Revision history for this message
Chris Halse Rogers (raof) wrote : Proposed package upload rejected

An upload of apparmor to noble-proposed has been rejected from the upload queue for the following reason: "dpkg-source: warning: diff 'apparmor-4.0.1/debian/patches/ubuntu/profiles-fix-wike-profile-location-to-apparmor.d.patch' doesn't contain any patch - you can't rename files in a diff!".

Revision history for this message
Chris Halse Rogers (raof) wrote :

Ok, I've reviewed the upload in the queue. I've rejected it, as one of the patches was broken, but apart from that the diff looks OK (although there's a *lot* of it, most of it is removal of autogenerated autoconf stuff).

If we're going to use just this bug for verification, please update the other bugs making it clear that they don't need to be verified as per https://wiki.ubuntu.com/StableReleaseUpdates#Bug_references_in_changelogs

Also, it looks like the verification test plan needs to be augmented? From the above discussion there seems to be a requirement to test some specific bubblewrap functionality, which should be added to the test plan.

Although, since it seems like the wike fix was accidentally not applied, maybe we should also test to ensure that the new profiles work, at least the more important applications?

description: updated
Revision history for this message
Georgia Garcia (georgiag) wrote :

Thanks for reviewing, Chris. I have updated the test plan with your suggestions, and I also updated the ppa containing a new version of the package with the wike profile location fixed. I'll also make sure to comment on the bugs in the changelog that verification is not required.

description: updated
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.