# Current State of the package ## Installation conflicts
As you noted, two profiles will have to be removed from this FFE because they clash with existing profiles and trigger an installation error: - pollinate - cockpit. ## CPU time 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. ## Memory usage Apparmor.d also significantly increases (kernel) memory usage. For this reason, with default settings, some autopkgtest fail to due to OOM. Failing tests with the default autopkgtest are: - borgbackup - borgbackup2 - cups-browsed - landscape-client - open-iscsi - qtox - rsyslogd Increasing the VM memory allows these tests to pass. Note: Simply removing the related package doesn't help, as the issue is due to the memory cost of having all profiles loaded, and not any individual profile. # Goals ## Optimization We are currently investigating policy optimization in order to reduce very significantly its load time and memory footprint. Some of the approaches we are working on are: - Userspace (pre-)compression of policies - DFA optimization - Shared resources between profiles (for abstractions) - Loading only profiles for packages that are installed - ... When these are ready, we expect enabling apparmor.d to be acceptable in production in most environments. ## Who will test this profile Anyone can test this package. We expect that only few people will do so initially due to the above constraints, but that more and more people will get interested when the profiles stabilize and resource usage drops. We also will use the autopkgtests to get representative usage of these software and improve associated profiles. Separating apparmor.d from the main repository simplifies maintenance and allows to update these packages separately. This makes sense as the two packages don't have the same level of criticality. ## Why not ship profiles in their own repositories For most profiles, we believe that maintaining a centralized copy of packages is the cleanest approach. - 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. - That also allows updating profiles without needing to update the application package. - It keep a centralized place for profiles - We try to make upstream profiles distro agnostic Now, some critical packages ship their own profiles. This can be preferable in specific cases but should remain the exception rather then the rule. ## Long-term goal Once policies are sufficiently stabilized and optimized, the long-term goal is to install these profiles in enforce mode (not complain mode) in order to significantly improve the system security. For Ubuntu, we aim at covering all of main. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2121409 Title: [FFE] add a new apparmor.d package containing several apparmor profiles To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2121409/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
