Notes from the open discussion

Finally, we had an open discussion, half brainstorming ideas and half "ask me anything about AppArmor". This was not what we had planned and I failed to adjust, so I failed to facilitate it as well as I would like; as a result, only a dozen or so people participated. Still, this was an interesting conversation.

Here's a summary of what we discussed:

• We clarified why we had to disable by default the AppArmor profile for Thunderbird (tl;dr: we got tons of bug reports, which increased the workload of Thunderbird and AppArmor maintainers way too much, and confirmed that AppArmor is not ideal for sandboxing apps that can be configured and extended in such a flexible way, e.g. with add-ons).
• On AppArmor profile shipped in Stretch was untested and very broken, which was painfully noticed when Linux from stretch-backports enabled AppArmor. We had to disable that profile in a Stretch point-release. This kind of issues should happen very rarely once AppArmor is enabled by default: package maintainers won't need to go out of their way to test packages with AppArmor enabled before uploading.
• A question was raised about Portals, so we explained the underlying design concept, implementation status and relationship to Flatpak, snaps and AppArmor.
• A few people were interested in developing systems to monitor and report policy violations, e.g. as a way to detect attacks ongoing in the wild. This data could be useful to system administrators and to upstream developers.
• We discussed a bit the privacy and implementation issues with extending reportbug to provide information about the AppArmor status of the buggy software (profile enforced? policy violations logged?).
• We discussed documentation.
  • It seems that the one we have already is not well known. We should advertise it better.
  • Someone suggested to add a README.AppArmor in packages to help users understand what's going on. The thunderbird package does that already.
  • Various ways to encourage package maintainers to write/include AppArmor profiles were brainstormed. The risk of nagging people with irrelevant suggestions is a concern though, so maybe this should be done in a more fine-grained way, e.g. for packages with frequent security issues, or focusing on the cases where a profile exists already.
• How to communicate AppArmor sandboxing as a differentiator that users could use when choosing software? One could use debtags or expose this info in GNOME Software, but doing so for desktop apps would create a false impression of security.
• We discussed how new AppArmor mediation features are handled. In Debian we enable a specific subset of the features the kernel supports, with a mechanism called "feature pinning". So we control when we enable new mediation features and can do that after having tested that the policy we have in the archive takes them into account.
• Ideally upstream authors of confined software would maintain the AppArmor profiles themselves: they're well placed to know what their software does and what permissions it needs. But:
  • For this to happen, upstream needs to see the need, which made us discuss again the idea to report policy violations to upstream when AppArmor successfully blocks attacks.
  • If upstream uses a Fedora / Red Hat distro, until LSM stacking is supported in Linux mainline, it's too painful for them to test things with AppArmor.