Here are some more thoughts from me. This took me a long time to write, read, and rewrite. Consider this me brainstorming on pros and cons. I like apparmor and am happy to see a push to confine more applications, and thanks for offering a strategy for doing that.
> The number of policies in this package is very large. When no policy cache > exists (as on first > installation), building it can be very long. Even when a cache, loading all > policies is not > instantaneous. The upgrade took double the time, and there were no changes. I just repeated "dpkg -i" with the same package. I also noticed the package doesn't use dh_apparmor, so no dh_apparmor snippets are in the rendered postinst, maybe that is where some debhelper smarts are missing. I didn't investigate further. > - It allows the AppArmor team to review carefully profiles, maintain them, > ensure their coherency and > how they interact with each other. > - It allows to decouple profiles from the application maintainers, that don't > necessarily have the > necessary AppArmor knowledge. But I think we would want coupling. Without it, the profile can evolve in one direction, and the application in another, and the confinement will break. You could have an old version of the profile installed and a new version of the application package installed. Users could have pinned an application package to a specific version. Users could want a profile fix from bin:apparmor.d-N+1, but keep another profile shipped in bin:apparmor.d-N for another application because in N+1 it broke their use case. > - That also allows updating profiles without needing to update the application package. Conversely, you would be updating a package that ships 1500 profiles. You would be fixing a bug for one profile, and could be introducing a bug in another (bugs happen). I think at the core I have two objections to this whole approach: 1) all profiles loaded even when not needed, leading to the problems in comment #6. You explained several optimizations, but to me the best optimization is to not load what is not needed :) 2) decoupling with the application: high risk of the profile being meant for one version of the app, but a later one has different requirements that do not match the profile anymore. This discrepancy looks easier and quicker to catch if the profile is together with the application. Tee risk of updates to this single package approach also seems much higher. Now, you make a good point about package maintainers not necessarily having the apparmor knowledge, or even a desire to confine their application. Us suddenly injecting an apparmor profile into their package is rude and disruptive. And we would also have potentially up to 1500 new delta pieces added to debian packages. How can we crack this nut? Have you guys thought of ways to still ship all profiles in a separate binary package, but not load them unless they are needed? Unless the application they are meant to confine is installed? Can we play some tricks with triggers? I guess similar problems and discussions were had in the past about the kernel modules package (we have two binary packages for kernel modules IIRC), and linux-firmware (which also installs a whole bunch of binary blobs regardless if you have that hardware or not: you *could* have it in the future). But none of these are loaded by default: they are just files available on disk, in case they are needed. Some other thoughts: a) a promotion plan: what happens once a profile matures, and can be shipped with the application? What are the conditions? What packaging changes will be needed then? We will have to add careful breaks/replaces, following https://wiki.debian.org/PackageTransition to avoid conflicts like in comment #5 b) or is the plan to always ship the profile in the distro via bin:apparmor.d, to be available in case the application package is installed, and never ship it in the application package itself? Counting on the fact that the current installation times can be made faster and have it consume less memory? c) testing plan: how can the profiles from src:apparmor.d be tested? We would have to have an autopkgtest in src:apparmor.d for package bin:FOO that would install *both* bin:apparmor.d and bin:FOO, and from your comments looks like that fails due to OOM, going back to the optimization problem. d) what about more restricted systems like raspberry PIs, are they of scope for this package, at this stage? e) What will SRUs look like for src:apparmor.d? How many profiles would you be updating in one go? How many applications would have to be tested separately? f) What happens if I have a host spawning dozens of LXD containers, and all those containers install bin:apparmor.d? "Don't do it"? :) I also understand this is following an upstream project, which has all these profiles in a git repository/tarball, and having one source debian package mimicking that makes sense. But even with optimizations, unless they are really fantastic, I don't see right now what this will look like in the long term. Now, I'm not the final word on this. This just appeared on my radar for sponsorship reasons, and I have a passion for application confinement, having written some apparmor profiles in the recent past. I truly welcome others to join the discussion, and have no objections to be proven wrong. -- 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/2121409 Title: [FFE] add a new apparmor.d package containing several apparmor profiles Status in apparmor package in Ubuntu: Triaged Bug description: ## FFE ## This is a Feature Freeze Exception request for questing for the apparmor package and for a new source package called apparmor.d: I'd like to add a new source package called apparmor.d which contains over 1500 profiles from the upstream project apparmor.d [1] These profiles will be added in "complain" mode, which means that for a given action, if the profile rules do not grant permission the action will be allowed, but the violation will be logged with a tag of the access being ALLOWED. This is done because we want to test these profiles and enable others to test and add new rules to eventually improve the profiles. By adding these profiles in a new package which is not installed by default, regular users will not be affected. But users that would like to test and contribute to the profiles can install it. We want to add these profiles, even in complain mode, as a new package (and not part of the apparmor package) because labeling certain binaries could cause issues with existing policy, specially those that use "peer". Additionally, the large amount of profiles do take a while to compile by the parser in the first boot. After that, a cached version of the profiles can be loaded directly into the kernel by the parser which takes considerably less time. Note again that apparmor.d will not be installed by default, so this will only affect users that choose to install it. The benefits of this change is the ability to increase the amount of testing for these profiles, which will then enable us to eventually ship them in enforce mode. More profiles means more confined applications, which could lead to higher security. This is the first step towards that. This FFE also includes the apparmor package because we want to change the suggestion from the apparmor-profiles-extra package, which is no longer maintained and will be deprecated in the future, to the new apparmor.d. This is the PPA containing a built version of apparmor and apparmor.d: https://launchpad.net/~georgiag/+archive/ubuntu/apparmor.dinapparmor5/ These are the installation logs: georgia@sec2-questing-amd64:~/qrt-test-apparmor$ sudo apt install apparmor.d The following packages were automatically installed and are no longer required: apg libllvm19 linux-headers-6.15.0-3-generic xbitmaps cpp-14 libopengl0 linux-modules-6.15.0-3-generic xinit cpp-14-x86-64-linux-gnu libsframe1 linux-tools-6.15.0-3 xorg gcc-14-base libxcb-damage0 linux-tools-6.15.0-3-generic libclang1-19 libxkbcommon-x11-0 x11-apps libglu1-mesa linux-headers-6.15.0-3 x11-session-utils Use 'sudo apt autoremove' to remove them. Upgrading: apparmor Installing: apparmor.d Summary: Upgrading: 1, Installing: 1, Removing: 0, Not Upgrading: 86 Download size: 1,116 kB Space needed: 3,418 kB / 6,269 MB available Continue? [Y/n] WARNING: The following packages cannot be authenticated! apparmor apparmor.d Install these packages without verification? [y/N] y Get:1 http://192.168.122.1/debs/testing questing/ apparmor 5.0.0~alpha1-0ubuntu5 [853 kB] Get:2 http://192.168.122.1/debs/testing questing/ apparmor.d 0.015-1ubuntu1 [264 kB] Fetched 1,116 kB in 0s (20.6 MB/s) Preconfiguring packages ... (Reading database ... 240702 files and directories currently installed.) Preparing to unpack .../apparmor_5.0.0~alpha1-0ubuntu5_amd64.deb ... Unpacking apparmor (5.0.0~alpha1-0ubuntu5) over (5.0.0~alpha1-0ubuntu4) ... Selecting previously unselected package apparmor.d. Preparing to unpack .../apparmor.d_0.015-1ubuntu1_amd64.deb ... Unpacking apparmor.d (0.015-1ubuntu1) ... Setting up apparmor (5.0.0~alpha1-0ubuntu5) ... Installing new version of config file /etc/apparmor.d/hostname ... Reloading AppArmor profiles Skipping profile in /etc/apparmor.d/disable: brave Skipping profile in /etc/apparmor.d/disable: chrome Skipping profile in /etc/apparmor.d/disable: chromium Skipping profile in /etc/apparmor.d/disable: dig Skipping profile in /etc/apparmor.d/disable: element-desktop Skipping profile in /etc/apparmor.d/disable: epiphany Skipping profile in /etc/apparmor.d/disable: firefox Skipping profile in /etc/apparmor.d/disable: flatpak Skipping profile in /etc/apparmor.d/disable: foliate Skipping profile in /etc/apparmor.d/disable: free Skipping profile in /etc/apparmor.d/disable: fusermount3 Skipping profile in /etc/apparmor.d/disable: hostname Skipping profile in /etc/apparmor.d/disable: locale Skipping profile in /etc/apparmor.d/disable: loupe Skipping profile in /etc/apparmor.d/disable: lsblk Skipping profile in /etc/apparmor.d/disable: lsusb Skipping profile in /etc/apparmor.d/disable: msedge Skipping profile in /etc/apparmor.d/disable: nslookup Skipping profile in /etc/apparmor.d/disable: openvpn Skipping profile in /etc/apparmor.d/disable: opera Skipping profile in /etc/apparmor.d/disable: os-prober Skipping profile in /etc/apparmor.d/disable: plasmashell Skipping profile in /etc/apparmor.d/disable: signal-desktop Skipping profile in /etc/apparmor.d/disable: slirp4netns Skipping profile in /etc/apparmor.d/disable: steam Skipping profile in /etc/apparmor.d/disable: systemd-coredump Skipping profile in /etc/apparmor.d/disable: systemd-detect-virt Skipping profile in /etc/apparmor.d/disable: thunderbird Skipping profile in /etc/apparmor.d/disable: transmission Skipping profile in /etc/apparmor.d/disable: unix-chkpwd Warning: found usr.sbin.sssd in /etc/apparmor.d/force-complain, forcing complain mode Warning from /etc/apparmor.d (/etc/apparmor.d/usr.sbin.sssd line 69): Caching disabled for: 'usr.sb in.sssd' due to force complain Skipping profile in /etc/apparmor.d/disable: virtiofsd Skipping profile in /etc/apparmor.d/disable: wg Skipping profile in /etc/apparmor.d/disable: wg-quick Skipping profile in /etc/apparmor.d/disable: who Setting up apparmor.d (0.015-1ubuntu1) ... Processing triggers for systemd (257.7-1ubuntu3) ... Processing triggers for man-db (2.13.1-1) ... Processing triggers for procps (2:4.0.4-8ubuntu2) ... georgia@sec2-questing-amd64:~/qrt-test-apparmor$ systemctl status apparmor \u25cf apparmor.service - Load AppArmor profiles Loaded: loaded (/usr/lib/systemd/system/apparmor.service; enabled; preset: enabled) Active: active (exited) since Fri 2025-08-29 12:09:41 -03; 21min ago Invocation: 7acd3f71e5084f50a7893334f2c2addf Docs: man:apparmor(7) https://gitlab.com/apparmor/apparmor/wikis/home/ Process: 13802 ExecReload=/lib/apparmor/apparmor.systemd reload (code=exited, status=0/SUCCESS) Main PID: 535 (code=exited, status=0/SUCCESS) Mem peak: 156.1M (swap: 268K) CPU: 5min 18.046s Aug 29 12:29:57 sec2-questing-amd64 apparmor.systemd[15293]: Skipping profile in /etc/apparmor.d/d> Aug 29 12:30:02 sec2-questing-amd64 apparmor.systemd[15328]: Skipping profile in /etc/apparmor.d/d> Aug 29 12:30:05 sec2-questing-amd64 apparmor.systemd[15373]: Skipping profile in /etc/apparmor.d/d> Aug 29 12:30:08 sec2-questing-amd64 apparmor.systemd[15437]: Warning: found usr.sbin.sssd in /etc/> Aug 29 12:30:08 sec2-questing-amd64 apparmor.systemd[15437]: Warning from /etc/apparmor.d (/etc/ap> Aug 29 12:30:13 sec2-questing-amd64 apparmor.systemd[15456]: Skipping profile in /etc/apparmor.d/d> Aug 29 12:30:19 sec2-questing-amd64 apparmor.systemd[15483]: Skipping profile in /etc/apparmor.d/d> Aug 29 12:30:19 sec2-questing-amd64 apparmor.systemd[15484]: Skipping profile in /etc/apparmor.d/d> Aug 29 12:30:19 sec2-questing-amd64 apparmor.systemd[15492]: Skipping profile in /etc/apparmor.d/d> Aug 29 12:30:31 sec2-questing-amd64 systemd[1]: Reloaded apparmor.service - Load AppArmor profiles. For testing, I ran the QA Regression Tests [2]: Steps: $ git clone https://git.launchpad.net/qa-regression-testing $ ./scripts/make-test-tarball ./scripts/test-apparmor.py Copying: test-apparmor.py Copying: testlib.py Copying: install-packages Copying: packages-helper Copying: apparmor/ Test files: /tmp/qrt-test-apparmor.tar.gz To run, first install the apparmor.d package introduced in this FFE, then copy the tarball somewhere, then do: $ tar -zxf qrt-test-apparmor.tar.gz $ cd ./qrt-test-apparmor $ sudo ./install-packages test-apparmor.py $ ./test-apparmor.py -v This script runs various tests against the installed apparmor package The result was: FAILED: disconnected_mount_complain socketpair make: *** [Makefile:487: alltests] Error 1 ---------------------------------------------------------------------- Ran 62 tests in 3949.185s FAILED (failures=1, skipped=4) Note that these failures are not related to the apparmor.d package and are also reproducible with apparmor version 5.0.0~alpha1-0ubuntu4 from the archive. [1] https://github.com/roddhjav/apparmor.d [2] https://git.launchpad.net/qa-regression-testing/tree/scripts/test-apparmor.py To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2121409/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
