Bonsoir, Le vendredi 17 janvier 2020, 03:08:05 CET Jonathan Leroy - Inikup via FRsAG a écrit :

AppArmor est désormais activé par défaut depuis Debian Buster. Je me pose la question de savoir si certains d'entre vous l'utilisent sur des serveurs de production, et de l'avis que vous en avez le cas échéant ?

C'est activé sur tous les serveurs que j'administre (taille PME dont le coeur de métier est dans l'informatique mais pas le web), et quasiment tous les services qui communiquent avec l'extérieur ont un profil en mode "enforce", y compris le php du wordpress.

J'ai beaucoup utilisé grsecurity par le passé et ai fini par faire machine arrière, car je passais plus de temps à rechercher l'origine de segfaults et à créer des règles qu'à travailler sur la tâche sur laquelle je devais travailler initialement.

Je n'ai jamais utilisé grsec, mais ce retour d'expérience ressemble beaucoup a selinux : soit c'est prévu dans le profil et c'est simple a condition de trouver la doc, soit il faut y passer des heures pour adapter, ou faire le gros bourrin ... Ce n'est pas mon expérience avec apparmor. Les adaptations de profils sont simples, et les profils lisibles par un humain. Je n'ai pas souvenir d'avoir vu des segfault, mais des deny dans les cas tordus de certains services (comme la gestion d'erreur) ça arrive, surtout quand on essaye d'être trop strict. Il faut avoir un suivi des logs.

Alors certes AppArmor est beaucoup moins "intrusif" que grsec, et j'imagine que la plupart des paquets Debian fournissent le profil qui va bien,

Non, il n'y a que très peu de profils fournis pour l'instant. Ubuntu a une bien meilleure couverture. Les exemples fournis par les paquets apparmor-* sont en général complètement obsolètes et nécessitent des changements.

mais je suis preneur de retours d'expérience réels de la vraie vie véritable. :)

- il faut la plupart du temps soit écrire le profil soit même, soit aller le chercher dans les paquets ubuntu ou suse. Compter de quelques dizaines de secondes a quelques dizaines de minutes par service pour écrire un profil, en fonction de la complexité : avec/sans appels a des programmes externe (genre script, le plus pénible), multi-binaires (dovecot, postfix), root/user ... - certains services sont pénibles, comme souvent les trucs en java : c'est souvent un script shell (souvent dispensable) qui cherche la jvm, définit le classpath et autres variables, et lance le binaire java trouvé. Il faut donc soit appliquer le profil dans le service systemd, soit sur le script, et du coup le profil doit aussi couvrir le script shell. Ou refaire le service pour éviter le script ... - les configurations locales nécessitent souvent des adaptations (il y un local.d/ pour ça) par rapport au profil générique, comme l'emplacement des données. C'est rapide, ca va. - installer auditd et audispd-plugins avec syslog activé (/etc/audisp/ plugins.d/syslog.conf), et avoir des alertes sur les deny AVC (et les audit éventuellement) - utiliser les outils aa-{complain,disable,enforce,enable} (ou faire les liens a la main) plutôt que d'éditer les profils - utiliser les #include <abstraction/...> plutôt que des règles manuelles - le comportement est parfois différent entre les modes complain et enforce : même sans alertes en complain, il arrive qu'au passage en enforce ça râle. - pour appliquer le profil, il faut la plupart du temps redémarrer le service complet après le reload du profil - les profils imbriqués (nested) dans des conteneurs ne sont pas supportés, ce n'est applicable que sur le conteneur complet et c'est complexe (j'ai laissé tomber) - les transitions entre sous profils (comme dans le cas d'un script) sont pénibles. En général c'est plus simple de tout mettre dans le même sous profil, avec des règles d'héritage (ix) - la granularité est beaucoup moins fine que selinux (et donc moins complexe), on ne gère pas les syscalls (utiliser systemd en complément si besoin), et on se contente la plupart du temps de régler les accès aux fichiers et les capabilities, surtout que : ... - certaines directives sont sans effet sous debian (pas de support noyau), comme les règles network. Pareil, utiliser systemd en complément si besoin d'interdire les accès réseau ou autre - la doc décrit assez bien la syntaxe (en EBNF et texte), mais reste assez théorique, manque d'exemples concrets, et est assez vague sur ce qui fonctionne ou pas sous debian - ne pas tenter sur les programmes utilisateur d'une station de travail ... - après la config initiale, en général ça roule, je ne retouche que rarement les profils - ca m'a déjà évité l'exploitation d'une faille joomla il y a quelques années. J'ai eu l'alerte (accès interdit), mais l'exploit n'a pas fonctionné En espérant que ca aide ...