**AppArmor** est une amélioration du noyau pour confiner les **programmes** à un **ensemble limité de ressources** avec des **profils par programme**. Les profils peuvent **autoriser des capacités** telles que l'accès au réseau, l'accès aux sockets bruts et la permission de lire, écrire ou exécuter des fichiers sur des chemins correspondants.
* **Exécution**: Les profils chargés en mode exécution entraîneront **l'application de la politique** définie dans le profil **ainsi que la signalisation** des tentatives de violation de la politique (soit via syslog, soit via auditd).
* **Plainte**: Les profils en mode plainte **n'appliqueront pas la politique** mais **signalent** plutôt les tentatives de **violation de la politique**.
AppArmor diffère de certains autres systèmes MAC sur Linux : il est **basé sur le chemin**, il permet le mélange de profils en mode exécution et en mode plainte, il utilise des fichiers d'inclusion pour faciliter le développement et il a une barrière d'entrée bien plus faible que d'autres systèmes MAC populaires.
Les profils Apparmor sont généralement enregistrés dans _**/etc/apparmor.d/**_\
Avec `sudo aa-status`, vous pourrez lister les binaires qui sont restreints par un profil. Si vous pouvez changer le caractère "/" pour un point du chemin de chaque binaire répertorié, vous obtiendrez le nom du profil apparmor à l'intérieur du dossier mentionné.
* Pour indiquer l'exécutable affecté, les **chemins absolus et les caractères génériques** sont autorisés (pour la recherche de fichiers) pour spécifier les fichiers.
* Pour indiquer l'accès que le binaire aura aux **fichiers**, les **contrôles d'accès** suivants peuvent être utilisés :
* **r** (lecture)
* **w** (écriture)
* **m** (cartographie de la mémoire en tant qu'exécutable)
* **k** (verrouillage de fichier)
* **l** (création de liens durs)
* **ix** (pour exécuter un autre programme avec le nouveau programme héritant de la politique)
* **Px** (exécuter sous un autre profil, après nettoyage de l'environnement)
* **Cx** (exécuter sous un profil enfant, après nettoyage de l'environnement)
* **Ux** (exécuter sans confinement, après nettoyage de l'environnement)
* Des **variables** peuvent être définies dans les profils et peuvent être manipulées depuis l'extérieur du profil. Par exemple : @{PROC} et @{HOME} (ajouter #include \<tunables/global> au fichier de profil)
* Les **règles de refus sont prises en charge pour remplacer les règles d'autorisation**.
Pour commencer facilement à créer un profil, apparmor peut vous aider. Il est possible de faire **inspecter les actions effectuées par un binaire par apparmor, puis de vous laisser décider quelles actions vous voulez autoriser ou refuser**.\
Ensuite, dans la première console, appuyez sur "**s**" et indiquez ensuite si vous voulez ignorer, autoriser ou autre chose pour les actions enregistrées. Lorsque vous avez terminé, appuyez sur "**f**" et le nouveau profil sera créé dans _/etc/apparmor.d/path.to.binary_
Notez que par défaut, dans un profil créé, rien n'est autorisé, donc tout est refusé. Vous devrez ajouter des lignes comme `/etc/passwd r,` pour autoriser la lecture du binaire `/etc/passwd`, par exemple.
Par défaut, le profil **Apparmor docker-default** est généré à partir de [https://github.com/moby/moby/tree/master/profiles/apparmor](https://github.com/moby/moby/tree/master/profiles/apparmor)
* Aucune **capacité** n'est définie (Cependant, certaines capacités proviendront de l'inclusion de règles de base de base, c'est-à-dire #include \<abstractions/base>)
* L'**écriture** dans n'importe quel fichier **/proc** n'est **pas autorisée**
* Les autres **sous-répertoires/fichiers** de /**proc** et /**sys** se voient **refuser** l'accès en lecture/écriture/verrouillage/liens/exécution
* Le **montage** n'est **pas autorisé**
* **Ptrace** ne peut être exécuté que sur un processus confiné par le **même profil apparmor**
Notez que **apparmor bloquera même les privilèges de capacités** accordés au conteneur par défaut. Par exemple, il sera capable de **bloquer la permission d'écrire à l'intérieur de /proc même si la capacité SYS_ADMIN est accordée** car par défaut, le profil apparmor de docker refuse cet accès:
Notez que vous pouvez **ajouter/supprimer** des **capacités** au conteneur Docker (cela sera toujours restreint par des méthodes de protection telles que **AppArmor** et **Seccomp**):
Généralement, lorsque vous **découvrez** que vous avez une **capacité privilégiée** disponible **à l'intérieur** d'un **conteneur docker mais** que certaines parties de l'**exploit ne fonctionnent pas**, cela est dû à ce que **AppArmor de docker l'empêche**.