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.base

Minimal core with tunables, abstractions, and dependencies of other profiles such that one can use this package if they only want to confine a given profile such as a server app, a GUI app without having to confine the rest of the system.

Possible issues: dbus may not be part of base and peer_label should be handled accordingly.

apparmor.d.core

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.

Ideally, this package should only have base as strict dependency. However, it may lead to issue.

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.

[beroal]

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 user can always boot from a live medium and switch the offending profiles to the complain mode. Booting from a live medium is a skill obligatory for every advanced computer user. I'm afraid that at this stage of program-level (as opposed to user-level) security in Linux, almost anything can break the system. Actually, if you can't edit profiles yourself, you aren't ready for it.

[beroal]

But what are the exact advantages? Sure, apparmor_parser is not very fast but for most users this should not cause any problems.

If AppArmor becomes slow because it deals with many profiles, than the right solution is to install profiles automatically when OS program packages are installed. This requires integration with package managers.

[roddhjav]

Current stage of implementation is available of #578. For now, it is only a WIP, some internal check still is missing. Also, all profile from core and base should have integration tests, therefore #583 is a requirement

100% stability cannot be guaranteed for rolling distros anyhow.

Rolling distro are by construction always in beta stage yes. However:

• Integration tests that target system such as systemd or Gnome can be run on the dev version and therefore, issue can be detected before the release.
• Most distro are not rolling one... stability on server is a must have for a security profile.

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:

Absolutely no:

Security policies are to be managed by system admin and system vendor. Not by user. System admin and vendor (the distribution) do it by deploying the full policies in a declarative way such as:

• A configuration package
• An Ansible playbook
• A systemd configuration extension

Any other option pose a risk:

• How do you ensure the policies are legitimate
• How do you ensure your /etc/apparmor.d is in the expected stage.

However

With the new condition feature coming in apparmor, I plan to add a aa-config tool that will allow system admin to quickly (and safely) set/enable special configuration on (a lot of) profiles (similar to the selinux boolean).

Similarly, apparmor will soon support rule priority that will enable some more advanced overwrite.

The user can always boot from a live medium and switch the offending profiles to the complain mode. Booting from a live medium is a skill obligatory for every advanced computer user.

Apparmor is an internal part of the security of an Linux distribution. Ideally the end user should not have to know that apparmor is a thing and is installed. The full apparmor.d should be able to run perfectly on any (compatible) distribution setup. This is clearly the goal of this project and the target to achieve before releasing a 1.0 version.

Meanwhile, apparmor can also be used for more advanced security configuration and should provide all required tooling (aa-log, aa-config...) for it (cf FSP).

[odomingao]

Security policies are to be managed by system admin and system vendor. Not by user. System admin and vendor (the distribution) do it by deploying the full policies in a declarative way

Sorry but I do not understand.. you mean that the end user with root/wheel privileges should not be able to install or configure apparmor profiles? I understand that you want pre-baked packages that distributions can adopt by default and I can see how it makes sense for distros, but I don't see how having such a tool would pose a security risk.

How do you ensure the policies are legitimate

By trusting the repository, TLS, maybe PGP?

How do you ensure your /etc/apparmor.d is in the expected stage.

What do you mean by this?

[roddhjav]

Sorry but I do not understand.. you mean that the end user with root/wheel privileges should not be able to install or configure apparmor profiles?

They can install (with a pm) and configure (not manually), however, your proposal was to fully give control to a wheel user to handle all profiles (while we currently give this power to the distribution). It may raise security issue yes but it can also become a maintenance hell:

• Setting flags are not that easy and have (security) consequences (eg: attach_disconnected)
• I am not willing to have to support and reply to issues from all special config a end user may have set. These profiles are not meant to be touched a lot by external user.

My position is that setting security policies is one of the most privileged task a Linux system can do (and the most effective way to break your system if not done correctly). The mac_admin capability can limit (and even provide) accesses that even a root program will have to comply with. Therefore in a production environment (server, mobile) MAC rules are often considered as fully read only by anyone but the package manager.

It also needs to be fully declarative to comply with modern server/desktop management method (so no UI by default).

By trusting the repository, TLS, maybe PGP?

In short, let your favourite package manager verify the authenticity of your apparmor profiles. Local admin addition can be set, however, they should be minimal (they can also be signed see systemd configuration extension)

How do you ensure your /etc/apparmor.d is in the expected stage.
What do you mean by this?

It is easy to mess up your own /etc/apparmor.d directory by adding/editing profiles from different sources. It usually ends badly (does not reboot). An easy way to avoid this is to never touch the policies and only apply tested rules from a project that manage policies (apparmor.d, apparmor, your own configuration package...)