Banque de connaissances en logiciels libres
Une compilation de documentations   { en , fr }

Prise en main et utilisation de AppArmor

Étiquettes:
Créé en:
Dernière modification:
Auteur:
Xavier Béguin

Présentation générale

AppArmor est un système de contrôle d'accès obligatoire pour Linux (en anglais Mandatory Access Control, ou MAC) qui met en œuvre les modules de sécurité Linux (Linux Security Modules, ou LSM).

Ce système permet de limiter :

  • les accès aux fichiers ;
  • les accès au réseau ;
  • l'utilisation des capacités Linux (capabilities, c'est à dire les différents privilèges associés au superutilisateur) ;
  • l'utilisation et des ressources systèmes (rlimits, processeurs, mémoire, nombre de processus ou de fichiers ouverts, etc.).

Il est semblable à SELinux (qui s'appuie lui aussi sur les LSM), avec quelques différences :

  • SELinux identifie les objets du système par leur nom, alors que AppArmor les identifie par leur chemin. Ceci signifie que sous AppArmor, un lien peut rendre un fichier accessible alors que ça ne serait pas le cas sous SELinux, et inversement : sous SELinux, copier un fichier vers un autre inœud peut le rendre accessible sous le même chemin, alors qu'il sera toujours inaccessible avec AppArmor ;
  • les règles de SELinux peuvent prendre en compte l'utilisateur invoquant le fichier, alors que AppArmor ne fait que compléter les listes d'accès traditionnels UNIX ;
  • SELinux est globalement considéré comme plus puissant mais ses règles sont aussi considérées plus complexes à mettre en place et à maintenir, rendant le système plus coûteux. AppArmor quant à lui ne permet pas toujours d'effectuer des règles aussi détaillées que SELinux, mais est en contrepartie plus facile à utiliser et maintenir.

Principe de mise en place

Description générale

Des profils de sécurité AppArmor associés à un fichier exécutable doivent être créés pour définir une politique de sécurité et chargés dans le noyau Linux qui les utilisera pour contrôler les accès des processus aux différentes ressources gérées.

Les profils associés aux exécutables qu'on souhaite contrôler par AppArmor doivent ensuite être explicitement passés dans l'un des modes suivants :

  • complain : c'est le mode d'audit / apprentissage qui ne fait que consigner dans les journaux système les violations de la politique définie par le profil mais ne les bloque pas (sauf les accès deny explitement interdits) ;
  • enforce : empêche réellement les violations de politique de sécurité du profil, en plus de les consigner dans les journaux système ;

Il est possible d'utiliser un mode audit, qui est un peu un mode debug qui empêche les violations de la politique de sécurité, comme enforce, mais consigne dans les journaux à la fois les violations de la politique sécurité et les règles autorisées.

Lorsqu'un exécutable est dans l'état unconfined, cela signifie que son profil n'est pas activé et que sa politique de sécurité n'est pas surveillée par le noyau (et que ses violations ne sont donc pas consignées dans les journaux).

Répertoires des profils

Les profils disponibles sont conservés dans le répertoire /etc/apparmor.d (sous les systèmes Debian GNU/Linux ; ce répertoire peut être différent sous d'autres systèmes), dans des fichiers portant comme nom le chemin de l'exécutable associé avec les slashs « / » remplacés par un point « . ». Par exemple le profile /etc/apparmor.d/usr.bin.man sera associé à /usr/bin/man. Cette notation permet de préciser indifféremment le profil de sécurité ou le chemin de l'exécutable en argument de la plupart des commandes d'AppArmor.

Les profils présents dans /etc/apparmor.d sont chargés automatiquement au démarrage dans le noyau par AppArmor (mais les exécutables associés ne sont pas confinés automatiquement). D'autres profils sont proposés par le paquet Debian apparmor-profiles dans le répertoire /usr/share/apparmor/extra-profiles/, et quelques autres par le paquet apparmor-profiles-extra. D'autres profils peuvent être trouvés dans le wiki de l'équipe de sécurité d'Ubuntu , en gardant à l'esprit que la plupart des profils doivent être testés et vérifiés avant utilisation.

Mise en place d'un profil de sécurité

La procédure

Pour activer le contrôle d'un exécutable par AppArmor à partir d'un profil existant, il faut :

  • d'abord copier le profil dans le répertoire /etc/apparmor.d ;
  • charger ensuite le profil dans le noyau à l'aide de la commande apparmor_parser ;
  • puis passer l'exécutable dans le mode complain avec aa-complain,
  • tester et vérifier les logs produits par AppArmor pendant l'utilisation de l'exécutable (en lisant, sous Debian, /var/log/syslog ou /var/log/kern.log) ;
  • quand tout fonctionne bien, passer l'exécutable en mode enforce avec la commande aa-enforce pour réellement interdire toute violation de la politique de sécurité.

La commande aa-status permet de vérifier l'état de AppArmor et le nombre de profils chargés dans les différents modes, ainsi que les processus existants ayant un profil défini et le mode dans lequel ils sont.

La commande aa-unconfined permet de voir simplement les processus dont les exécutables possèdent un profil, et s'ils sont confinés (confined) et dans quel mode, ou non confinés (unconfined).

Un exemple

Exemple pour l'exécutable /usr/bin/sshd en utilisant un profil fourni par apparmor-profiles :

  • copie du profil vers /etc/apparmor.d/ :
    cp /usr/share/apparmor/extra-profiles/usr.sbin.sshd /etc/apparmor.d/
  • chargement du profil dans le noyau :
    apparmor_parser -a /etc/apparmor.d/usr.sbin.sshd
  • syslog montre le chargement du profile de /usr/sbin/sshd ainsi que son sous-profil /usr/sbin/sshd/passwd :
    May 14 12:14:58 xlab1 kernel: [359606.249974] audit: type=1400 audit(1557850498.557:36): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/sbin/sshd" pid=8103 comm="apparmor_parser"
May 14 12:14:58 xlab1 kernel: [359606.250571] audit: type=1400 audit(1557850498.557:37): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/sbin/sshd//passwd" pid=8103 comm="apparmor_parser"
  • passage de l'exécutable en mode complain :
    aa-complain /usr/sbin/sshd
  • lecture des logs, où on verra au minimum que la commande aa-complain a entraîné une demande de rechargement du profil :
    May 14 12:20:25 xlab1 kernel: [359932.933851] audit: type=1400 audit(1557850825.241:38): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/sbin/sshd" pid=8244 comm="apparmor_parser"
May 14 12:20:25 xlab1 kernel: [359932.949110] audit: type=1400 audit(1557850825.257:39): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="/usr/sbin/sshd//passwd" pid=8244 comm="apparmor_parser"
  • si aucune violation n'est consignée dans les journaux dans syslog après une utilisation complète du logiciel (y compris un démarrage et arrêt dans le cas d'un daemon), on pourra le passer en mode enforce :
    aa-enforce /usr/sbin/sshd

aa-status montrera que le processus sshd est en mode complain (ou plus tard enforce) :

# aa-status 
apparmor module is loaded.
23 profiles are loaded.
7 profiles are in enforce mode.
   /usr/bin/man
   /usr/sbin/ntpd
   /usr/sbin/sshd//passwd
   (...)
16 profiles are in complain mode.
   /usr/sbin/dnsmasq
   /usr/sbin/dnsmasq//libvirt_leaseshelper
   /usr/sbin/sshd
   (...)
   traceroute
3 processes have profiles defined.
1 processes are in enforce mode.
   /usr/sbin/ntpd (325) 
2 processes are in complain mode.
   /usr/sbin/sshd (1344) 
   /usr/sbin/sshd (1345) 
0 processes are unconfined but have a profile defined.

La commande aa-unconfined montre aussi les informations sur les processus en cours ayant un profil :

# aa-unconfined 
308 /usr/sbin/nrpe not confined
325 /usr/sbin/ntpd confined by '/usr/sbin/ntpd (enforce)'
1344 /usr/sbin/sshd confined by '/usr/sbin/sshd (complain)'

Le résultat de aa-status et aa-unconfined ne va pas montrer le résultat attendu pour les processus qui ont été démarré avant que AppArmor n'ait été chargé.

Dans ce cas, même après une commande aa-complain ou aa-enforce, le processus apparaitra comme étant non confiné (en mode unconfined), alors que les logs montrent bien qu'il est maintenant confiné en mode complain ou enforce.

Il suffit de redémarrer les processus pour corriger ce petit souci (qui ne devrait arriver que lorsque AppArmor a été fraîchement chargé).

Création d'un nouveau profil

La génération d'un nouveau profil peut se faire manuellement en plaçant un ensemble de règles dans un nouveau fichier sous /etc/apparmor.d/. Cette opération peut être nettement facilitée à l'aide de la commande aa-genprof, qui va elle-même faire appel à la commande aa-logprof pour générer le profil à partir des violations détectée dans les logs en mode complain.

La génération d'un nouveau profil avec aa-genprof s'effectue simplement en appelant la commande avec le nom de l'exécutable. Par exemple, pour générer un profil pour /sbin/dhclient :

aa-genprof dhclient

Cet outil va nous guider pour faciliter la création d'un nouveau profil :

  • il passe l'exécutable en mode complain ;
  • il demande qu'on utilise de façon la plus exhaustive possible l'exécutable ;
  • aa-genprof propose ensuite de lancer aa-logprof qui va scanner les logs pour repérer les violations du programme, et génère un nouveau profil dont il demande d'accepter ou corriger chaque règle (par exemple pour faire porter les règles d'accès sur /run/dhclient-*.pid au lieu de /run/dhclient-eth0.pid), avant d'écrire le profil dans /etc/apparmor.d/sbin.dhcpd ;
  • aa-genprof propose enfin de terminer la génération du profil en le passant en mode enforced, puis le programme se termine.

Ces informations ont principalement été tirées du manuel aa-genprof(8) et du Debian Administrator's Handbook, ce dernier document montrant un exemple complet d'utilisation de aa-genprof.