AppArmor
Informations de base
AppArmor est une amélioration du noyau conçue pour restreindre les ressources disponibles aux programmes via des profils par programme, mettant en œuvre efficacement un contrôle d'accès obligatoire (MAC) en liant directement les attributs de contrôle d'accès aux programmes plutôt qu'aux utilisateurs. Ce système fonctionne en chargeant des profils dans le noyau, généralement au démarrage, et ces profils dictent quelles ressources un programme peut accéder, telles que les connexions réseau, l'accès aux sockets bruts et les autorisations de fichier.
Il existe deux modes opérationnels pour les profils AppArmor :
Mode d'application des règles (Enforcement Mode) : Ce mode applique activement les politiques définies dans le profil, bloquant les actions qui violent ces politiques et journalisant toute tentative de les violer via des systèmes tels que syslog ou auditd.
Mode de plainte (Complain Mode) : Contrairement au mode d'application des règles, le mode de plainte ne bloque pas les actions contraires aux politiques du profil. Au lieu de cela, il journalise ces tentatives en tant que violations de la politique sans imposer de restrictions.
Composants d'AppArmor
Module noyau : Responsable de l'application des politiques.
Politiques : Spécifient les règles et restrictions pour le comportement des programmes et l'accès aux ressources.
Analyseur : Charge les politiques dans le noyau pour l'application ou le signalement.
Utilitaires : Ce sont des programmes en mode utilisateur qui fournissent une interface pour interagir avec et gérer AppArmor.
Chemin des profils
Les profils AppArmor sont généralement enregistrés dans /etc/apparmor.d/
Avec sudo aa-status
, vous pourrez lister les binaires restreints par un profil. Si vous remplacez le caractère "/" par un point du chemin de chaque binaire répertorié, vous obtiendrez le nom du profil AppArmor à l'intérieur du dossier mentionné.
Par exemple, un profil AppArmor pour /usr/bin/man sera situé dans /etc/apparmor.d/usr.bin.man
Commandes
Création d'un profil
Afin d'indiquer l'exécutable affecté, les chemins absolus et les caractères génériques sont autorisés (pour le globbing 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 (mapping en mémoire comme exécutable)
k (verrouillage de fichiers)
l (création de liens physiques)
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 avoir nettoyé l'environnement)
Cx (exécuter sous un profil enfant, après avoir nettoyé l'environnement)
Ux (exécuter sans confinement, après avoir nettoyé 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} (ajoutez #include <tunables/global> au fichier de profil)
Les règles de refus sont prises en charge pour remplacer les règles d'autorisation.
aa-genprof
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 souhaitez autoriser ou refuser. Il vous suffit d'exécuter :
Ensuite, dans une console différente, effectuez toutes les actions que le binaire effectuera généralement :
Ensuite, dans la première console, appuyez sur "s" puis dans les actions enregistrées indiquez si vous voulez ignorer, autoriser, ou autre. Lorsque vous avez terminé, appuyez sur "f" et le nouveau profil sera créé dans /etc/apparmor.d/path.to.binary
En utilisant les touches fléchées, vous pouvez sélectionner ce que vous voulez autoriser/refuser/autre
aa-easyprof
Vous pouvez également créer un modèle de profil apparmor d'un binaire avec:
Notez qu'en créant un profil par défaut, 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.
Vous pouvez ensuite appliquer le nouveau profil avec
Modification d'un profil à partir des journaux
L'outil suivant lira les journaux et demandera à l'utilisateur s'il souhaite autoriser certaines des actions interdites détectées :
En utilisant les touches fléchées, vous pouvez sélectionner ce que vous voulez autoriser/refuser/autre
Gestion d'un profil
Journaux
Exemple de journaux AUDIT et DENIED du fichier /var/log/audit/audit.log de l'exécutable service_bin
:
Vous pouvez également obtenir ces informations en utilisant :
Apparmor dans Docker
Notez comment le profil docker-profile de docker est chargé par défaut:
Par défaut, le profil Apparmor docker-default est généré à partir de https://github.com/moby/moby/tree/master/profiles/apparmor
Résumé du profil docker-default:
Accès à tout le réseau
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>)
É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/blocage/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
Une fois que vous exécutez un conteneur docker, vous devriez voir la sortie suivante:
Notez que apparmor bloquera même les privilèges de capacités accordés au conteneur par défaut. Par exemple, il pourra bloquer l'autorisation 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:
Vous devez désactiver apparmor pour contourner ses restrictions :
Notez que par défaut AppArmor interdit également au conteneur de monter des dossiers de l'intérieur même avec la capacité SYS_ADMIN.
Notez que vous pouvez ajouter/supprimer des capacités au conteneur Docker (cela restera tout de même restreint par des méthodes de protection comme AppArmor et Seccomp):
--cap-add=SYS_ADMIN
donne la capacitéSYS_ADMIN
--cap-add=ALL
donne toutes les capacités--cap-drop=ALL --cap-add=SYS_PTRACE
supprime toutes les capacités et donne uniquementSYS_PTRACE
Généralement, lorsque vous constatez que vous avez une capacité privilégiée disponible à l'intérieur d'un conteneur Docker mais qu'une partie de l'exploit ne fonctionne pas, c'est probablement parce que AppArmor de Docker l'empêche.
Exemple
(Exemple provenant de ici)
Pour illustrer la fonctionnalité d'AppArmor, j'ai créé un nouveau profil Docker "mydocker" avec la ligne suivante ajoutée :
Pour activer le profil, nous devons faire ce qui suit :
Pour répertorier les profils, nous pouvons exécuter la commande suivante. La commande ci-dessous répertorie mon nouveau profil AppArmor.
Comme indiqué ci-dessous, nous obtenons une erreur lors de la tentative de modification de "/etc/" car le profil AppArmor empêche l'accès en écriture à "/etc".
Contournement d'AppArmor Docker1
Vous pouvez trouver quel profil apparmor exécute un conteneur en utilisant :
Ensuite, vous pouvez exécuter la ligne suivante pour trouver le profil exact utilisé :
Contournement d'AppArmor Docker Bypass2
AppArmor est basé sur les chemins, cela signifie que même s'il pourrait protéger les fichiers à l'intérieur d'un répertoire comme /proc
, si vous pouvez configurer comment le conteneur va être exécuté, vous pourriez monter le répertoire proc de l'hôte à l'intérieur de /host/proc
et il ne sera plus protégé par AppArmor.
Contournement de Shebang AppArmor
Dans ce bug, vous pouvez voir un exemple de comment même si vous empêchez perl d'être exécuté avec certaines ressources, si vous créez simplement un script shell spécifiant dans la première ligne #!/usr/bin/perl
et que vous exécutez le fichier directement, vous pourrez exécuter ce que vous voulez. Par exemple:
Last updated