RFC: Split the profiles in multiple packages.

[roddhjav]

This issue aims to be an open discussion about possible reorganization of how the profiles are shipped.

The current apparmor.d package ships a lot of profiles. Depending on the target system, they are not always needed or not always stable. It can be an issue for new user as they can be legitimately afraid of breaking their system even if over 90% of the profiles are safe to use.

The idea is to split the profiles in multiple packages. The project itself would remain a mono repository with all the profiles in it, as it make it easier to develop and maintain them.

Possible packages

apparmor.d.core

Minimal core with tunables, abstractions, and dependencies of other profiles. Profiles for program installed by default and common to all desktops and servers. Eg:

• coreutils (and similar)
• systemd
• dbus
• grub

All profile in core should be safe to be enforced by default (they may be a few exceptions such as udevd).

apparmor.d.desktop

Base desktop, also useful for unsupported DE. Equivalent of the following groups:

• freedesktop
• gvfs

apparmor.d.gnome, apparmor.d.kde, apparmor.d.xfce

Desktop specific package. Should conflict with each other. DE specific configuration (in gnome) may require us to have a conflict with apparmor.d.desktop too.

apparmor.d.browsers

All profiles related to browsers.

apparmor.d.app

Profiles related to UI applications. Could be split in multiple sub-packages.

apparmor.d.full

Like the current apparmor.d

Advantages

• Provide a core set of battle tested profiles that can safely be enforced by default.
• Only provide the minimal set of profiles required for a specific use case:
  • no more profiles for desktop on a server,
  • no profile for KDE on Gnome.
• DE specific package can only support one DE and ship DE specific configuration.
• A user using a DE not supported could still use the core package, the app package, and the browser package.
• In FSP mode, not having a profile means preventing the program from running.

Disadvantages

• Need to sort all profiles into groups/area to determine witch profiles goes where
• Need to ensure that profile dependencies are correctly set
• Need to ensure each possible combination of installed packages work.
• Lot of testing and possible maintenance.
• Breaking change would require manual update from current set-up

[nobody43]

I had thought about grouping and selecting profiles on package compilation, by your approach is better.

apparmor.d.core

I disagree on this. Mandatory part of the package (tunables and abstractions) needs to be decoupled from highly prone to system failure systemd* profiles.

I'm thinking about the following groups, based on coupling, chance of system failure and potential attack surface:

• tunables and abstractions - mandatory
• base system, including systemd* - this is where boot failures are most likely to happen
• DEs
• (listening) network services
• userland (not necessarily UI? userland is a bit more descriptive than generic apps)
• critical apps like browsers - users could want just high-risk apps and nothing more

Also, the project needs a profile deprecation mechanism. When user first installs it, he expects that listed packages will provide confinement, but on the following update certain profiles could silently disappear and protection will be gone. User needs to be explicitly notified.

Need to sort all profiles into groups/area to determine witch profiles goes where

Just additional comment in the header of a profile?

[roddhjav]

Most systemd profile are stable. Only a very few one are prone to failure or are too young to be considered as stable. It means that the profile selection should consider both the package group and some individual inclusion, for example to ship the full systemd group in core but not systemd-udevd.

In general the main objectives are too:

• Only install profiles that are needed for your system.
• Stability: the core packages should be 100% stable. Less stable pkg should be moved to other apparmor.d pkg.

(listening) network services

Do you have example of profile?

• userland (not necessarily UI? userland is a bit more descriptive than generic apps)

I don't want to ship profile for GUI program on server, therefore, I think we should spilt them. Thus, the profiles for UI app can depends on apparmor.d.desktop that is not installed on server.

Also, the project needs a profile deprecation mechanism.

I do agree. This is something I purposely did not work on yet thank to the 0.x version scheme we have.

[nobody43]

Most systemd profile are stable.

They sure are, but only under current version of the system, but under rolling release distro this profile group becomes brittle. Users who seek only protection of the browsers should not be forced to deal with such issues. Decoupled userland/browsers profiles could work almost anywhere, contrary to coupled core version which will work only under supported distros. If systemd/core apps are mandatory for protecting browsers - far less people will use the project.

Do you have example of profile?

avahi-autoipd?, openvpn, mullvad-daemon, containerd?, dockerd?, sshd, gnome-remote-desktop-daemon, goa-daemon, exim4, dnscrypt-proxy, dleyna-server-service, syncthing, ssserver, qbittorrent, rustdesk, murmurd; maybe more.

aa-unconfined will display currently listening network services, but some of them may be designed to run on localhost only, and attack surface may be not as severe.

I don't want to ship profile for GUI program on server, therefore, I think we should spilt them.

Some programs falls under multiple groups:

• qbittorrent - gui, service
• dnscrypt-proxy - cli, service
• gnome-remote-desktop-daemon - gui, service, DE (gnome)

Maybe we should tag and treat the profiles accordingly.

[roddhjav]

If systemd/core apps are mandatory for protecting browsers - far less people will use the project.

You have a good point here. Then we also need a apparmor.d.base or even a apparmor.d.systemd pkg.

Some programs falls under multiple groups

Yes, there is a bit of sorting and classification to do. It is possibly the biggest task here. We need to end up with a few configuration files in dist/ that define what profile/group goes where.

[curiosityseeker]

I haven't completely made up my mind yet about this proposed change but here are some thoughts.

In general the main objectives are too:

* Only install profiles that are needed for your system.

But what are the exact advantages? Sure, apparmor_parser is not very fast but for most users this should not cause any problems. So I wonder if all the problems coming from sorting and classification make this change worth doing.

* Stability: the core packages should be 100% stable. Less stable pkg should be moved to other apparmor.d pkg.

As already mentioned by @nobody43 the 100% stability cannot be guaranteed for rolling distros anyhow. The recent changes for mesa are an example for this.

That said, I think that apparmor.d.browsers and apparmor.d.app would make sense indeed as I've seen many requests about a good profile for, e.g., Firefox and other programs. So providing those 2 packages would probably improve the adaption of this project.

[odomingao]

I think that it would be a good idea to replace the current apparmor.d package with a CLI/TUI utility for managing profiles instead:

• allows the user to customize exactly what profiles they want (though groups or manually, with a UI similar to make menuconfig)
• allows for better user overrides than local/profile e.g. "always enforce profile X because I think it's stable", "always give profiles X Y Z the attach_disconnected flag"
• Allows for (maybe) notifying the user of breaking changes with critical packages that can lead to boot failures
• Allows for better management of custom and other projects' upstream profiles

Tagged groups for networked profiles that most people want enabled, and a group for core system profiles that some people would rather disable would IMO be a good way to start.

[nobody43]

https://github.com/jack-ullery/AppAnvil Maybe we should cooperate on interconnectivity with people already making the GUI rather than reinvent the wheel? It will be a nice symbiosis: we provide grouped profiles with the ability to fine grain it further by the GUI.

[curiosityseeker]

* allows for better user overrides than local/profile e.g. "always enforce profile X because I think it's stable", "always give profiles X Y Z the attach_disconnected flag"

I'm not sure how this is supposed to work as all individual changes would be overwritten by the next update.

we provide grouped profiles with the ability to fine grain it further by the GUI.

Above problem would also apply here.

[odomingao]

@curiosityseeker my proposal would avoid this as a configuration file for the apparmor tool should be kept locally (in e.g. ~/.config/apparmor.d/custom.flags) and the build process should source user changes from said file. The build and install process of the profiles should be automated by the proposed tool and no longer directly managed by the PKGBUILD or other distro package themselves. The package should only download this configuration utility.

[curiosityseeker]

@curiosityseeker my proposal would avoid this as a configuration file for the apparmor tool should be kept locally (in e.g. ~/.config/apparmor.d/custom.flags) and the build process should source user changes from said file. The build and install process of the profiles should be automated by the proposed tool and no longer directly managed by the PKGBUILD or other distro package themselves. The package should only download this configuration utility.

I see, thanks. I guess that would work if it comes to flags. But this is not a solution for other customizations.