AppArmor - amélioration du noyau pour confiner les programmes à un ensemble limité de ressources.
DESCRIPTION
AppArmor est une amélioration du noyau pour confiner les programmes à un ensemble limité de ressources. Le modèle de sécurité unique d'AppArmor consiste à lier les attributs de contrôle d'accès aux programmes plutôt qu'aux utilisateurs.
Le confinement AppArmor est fourni via des profils chargés dans le noyau via apparmor_parser(8), généralement via l'unité systemd apparmor.service, qui est utilisée comme suit :
# systemctl start apparmor
# systemctl reload apparmor
AppArmor peut fonctionner dans deux modes : application et signalement ou apprentissage :
application - Les profils chargés en mode application entraîneront l'application de la stratégie définie dans le profil ainsi que le signalement des tentatives de violation de la stratégie à syslogd.
signalement - Les profils chargés en mode « signalement » n'appliqueront pas la stratégie. Au lieu de cela, ils signaleront les tentatives de violation de la stratégie. Ce mode est pratique pour développer des profils. Pour gérer le mode signalement pour les profils individuels, les utilitaires aa-complain(8) et aa-enforce(8) peuvent être utilisés. Ces utilitaires prennent le nom d'un programme comme argument.
Les profils sont traditionnellement stockés dans des fichiers dans /etc/apparmor.d/ sous des noms de fichiers avec la convention de remplacer le / dans les chemins par . (sauf pour la racine /) afin que les profils soient plus faciles à gérer (par exemple, le profil /usr/sbin/nscd serait nommé usr.sbin.nscd).
Les profils sont appliqués à un processus au moment de exec(3) (tel qu'il est visible dans l'appel système execve(2)) : une fois qu'un profil est chargé pour un programme, ce programme sera confiné lors du prochain exec(3). Si un processus est déjà en cours d'exécution sous un profil, lorsque vous remplacez ce profil dans le noyau, le profil mis à jour est immédiatement appliqué à ce processus. D'un autre côté, un processus qui est déjà en cours d'exécution non confiné ne peut pas être confiné.
AppArmor prend en charge le système de fichiers securityfs du noyau Linux et rend disponible la liste des profils actuellement chargés ; pour monter le système de fichiers :
# mount -tsecurityfs securityfs /sys/kernel/security
$ cat /sys/kernel/security/apparmor/profiles
/usr/bin/mutt
/usr/bin/gpg
...
Normalement, le script d'initialisation monte securityfs s'il n'a pas déjà été monté.
AppArmor restreint également les opérations privilégiées qu'un processus confiné peut exécuter, même si le processus s'exécute en tant que root. Un processus confiné ne peut pas appeler les appels système suivants :
create_module(2) delete_module(2) init_module(2) ioperm(2)
iopl(2) ptrace(2) reboot(2) setdomainname(2) sethostname(2) swapoff(2) swapon(2) sysctl(2)
Mode de signalement
Au lieu de refuser l’accès aux ressources pour lesquelles le profil ne contient pas de règle, AppArmor peut « autoriser » l’accès et enregistrer un message pour l’opération qui le déclenche. C’est ce qu’on appelle le mode de signalement. Il est important de noter que les règles présentes dans le profil sont toujours appliquées, de sorte que les règles d’autorisation continueront à supprimer ou à forcer les messages d’audit, et les règles de refus entraîneront toujours des refus et la suppression des messages de refus (voir Désactiver la suppression des messages d’audit de refus si cela pose problème).
Le mode de signalement peut être utilisé pour développer des profils de manière incrémentale au fur et à mesure que l’application est exécutée. Les accès enregistrés peuvent être ajoutés au profil, puis l’application peut être exécutée davantage pour découvrir d’autres ajouts nécessaires. Étant donné qu’AppArmor autorise les accès, l’application se comportera comme si AppArmor ne la limitait pas.
Attention : le mode de signalement ne fournit aucune sécurité, uniquement un audit, pendant qu’il est activé. Il ne doit pas être utilisé dans un environnement hostile, car les comportements malveillants pourraient être enregistrés et ajoutés au profil comme s’il s’agissait d’accès aux ressources qui devraient être utilisés par l’application.
Remarque : le mode de signalement peut générer beaucoup de messages avec les nouveaux profils ou les profils vides, mais avec les profils développés, il peut ne rien enregistrer si le profil couvre bien le comportement de l’application. Voir Limitation du taux d’audit si le mode de signalement génère trop de messages de journal.
Pour définir un profil et tous les profils enfants ou de chapeau que le profil peut contenir en mode de signalement, utilisez :
aa-complain /etc/apparmor.d/<le-nom-de-l’application>
Pour définir manuellement un profil spécifique en mode de signalement, ajoutez l’indicateur « complain », puis rechargez manuellement le profil :
profile foo flags=(complain) { ... }
Notez que l’indicateur « complain » doit également être ajouté manuellement à tous les profils de chapeau ou enfants du profil, sinon ils continueront à utiliser le mode précédent.
Pour activer le mode de signalement globalement, exécutez :
echo -n complain > /sys/module/apparmor/parameters/mode
ou pour le définir au démarrage, ajoutez :
apparmor.mode=complain
en tant que paramètre de démarrage du noyau.
Attention : définir le mode de signalement globalement désactive toutes les protections de sécurité d’AppArmor. Il peut être utile pendant le débogage ou le développement de profils, mais il est plus sûr de le définir sélectivement pour chaque profil.
ERREURS
Lorsqu’un processus limité tente d’accéder à un fichier auquel il n’a pas l’autorisation d’accéder, le noyau signalera un message via l’audit, comme suit :
audit(1386511672.612:238) : apparmor="DENIED" operation="exec"
parent=7589 profile="/tmp/sh" name="/bin/uname" pid=7605
comm="sh" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
audit(1386511672.613:239) : apparmor="DENIED" operation="open"
parent=7589 profile="/tmp/sh" name="/bin/uname" pid=7605
comm="sh" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
audit(1386511772.804:246) : apparmor="DENIED" operation="capable"
parent=7246 profile="/tmp/sh" pid=7589 comm="sh" pid=7589
comm="sh" capability=2 capname="dac_override"
Les permissions demandées par le processus sont décrites dans les champs operation= et denied_mask=. Pour les fichiers (capacités, etc.), un format de journal légèrement différent est utilisé. Le « nom » et l’ID du processus du programme en cours d’exécution sont signalés, ainsi que le nom du profil, y compris tout « chapeau » qui pourrait être actif, séparés par « // ». (« Nom » est entre guillemets, car le nom du processus est limité à 15 octets ; il est identique à celui signalé via la comptabilité des processus Berkeley.)
Pour les processus confinés exécutés sous un profil qui a été chargé en mode de « plainte », l’application des règles ne se fera pas, et les messages de journal rapportés à audit auront la forme suivante :
audit(1386512577.017:275) : apparmor="AUTORISÉ" operation="open"
parent=8012 profile="/usr/bin/du" name="/etc/apparmor.d/tunables/"
pid=8049 comm="du" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
audit(1386512577.017:276) : apparmor="AUTORISÉ" operation="open"
parent=8012 profile="/usr/bin/du" name="/etc/apparmor.d/tunables/"
pid=8049 comm="du" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Si l’outil auditd en mode utilisateur n’est pas en cours d’exécution, le noyau enverra les événements d’audit à klogd ; klogd enverra les messages à syslog, qui enregistrera les messages avec l’installation KERN. Ainsi, les messages REJETANT et AUTORISANT peuvent aller soit vers /var/log/audit/audit.log, soit vers /var/log/messages, en fonction de la configuration locale.
DÉBOGAGE
AppArmor fournit quelques outils pour enregistrer plus d’informations, ce qui peut aider au débogage des profils.
Activer le mode débogage
Lorsque le mode débogage est activé, AppArmor enregistrera quelques messages supplémentaires dans dmesg (pas via le sous-système d’audit). Par exemple, les journaux indiqueront si le nettoyage de l’environnement a été appliqué.
Pour activer le mode débogage, exécutez :
echo 1 > /sys/module/apparmor/parameters/debug
ou pour le définir au démarrage, ajoutez :
apparmor.debug=1
en tant que paramètre de démarrage du noyau.
Désactiver la suppression des journaux d’audit de refus
Par défaut, les opérations qui déclenchent des règles de « refus » ne sont pas enregistrées. Ceci est appelé suppression des journaux d’audit de refus.
Pour désactiver la suppression des journaux d’audit de refus, exécutez :
echo -n noquiet >/sys/module/apparmor/parameters/audit
ou pour le définir au démarrage, ajoutez :
apparmor.audit=noquiet
en tant que paramètre de démarrage du noyau.
Forcer le mode d’audit
AppArmor peut enregistrer un message pour chaque opération qui déclenche une règle configurée dans la stratégie. Ceci est appelé mode d’audit forcé.
Attention ! Le mode d’audit forcé peut être extrêmement bruyant, même pour un seul profil, et encore plus lorsqu’il est activé globalement.
Pour définir un profil spécifique en mode d’audit forcé, ajoutez l’indicateur « audit » :
profile foo flags=(audit) { ... }
Pour activer le mode d’audit forcé globalement, exécutez :
echo -n all > /sys/module/apparmor/parameters/audit
ou pour le définir au démarrage, ajoutez :
apparmor.audit=all
en tant que paramètre de démarrage du noyau.
Limitation du taux d’audit
Si auditd n’est pas en cours d’exécution, afin d’éviter de perdre trop de messages de journal supplémentaires, vous devrez probablement désactiver la limitation du taux en exécutant :
echo 0 > /proc/sys/kernel/printk_ratelimit
Même dans ce cas, la mémoire tampon circulaire du noyau peut déborder et vous risquez de perdre des messages.
Autrement, si auditd est en cours d’exécution, consultez auditd(8) et auditd.conf(5).
FICHIERS
/etc/apparmor.d/
/var/cache/apparmor/
/var/log/audit/audit.log
/var/log/messages
VOIR AUSSI
apparmor_parser(8), aa_change_hat(2), apparmor.d(5), aa-autodep(1), clean(1), auditd(8),
aa-unconfined(8), aa-enforce(1), aa-complain(1) et [https://wiki.apparmor.net].