Salut à tous,
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 ?
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.
Alors certes AppArmor est beaucoup moins "intrusif" que grsec, et j'imagine que la plupart des paquets Debian fournissent le profil qui va bien, mais je suis preneur de retours d'expérience réels de la vraie vie véritable. :)
Merci.
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 ...
Bonjour,
j'ajoute une question à la fin de ce mail, sans que cela soit forcément pour un usage prochain (pour ma culture générale).
On Fri, 17 Jan 2020 19:54:15 +0100 Vincent Tondellier via FRsAG frsag@frsag.org wrote:
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.
(…)
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(…)
Je n'ai jamais utilisé grsec, mais ce retour d'expérience ressemble beaucoup a selinux ...
(…)
Ce n'est pas mon expérience avec apparmor. Les adaptations de profils sont simples
(…) (…)
mais je suis preneur de retours d'expérience réels
(…)
- il faut la plupart du temps soit écrire le profil soit même, soit aller le
chercher dans les paquets ubuntu ou suse
(………)
- la doc décrit assez bien la syntaxe (en EBNF et texte), mais reste assez
théorique, manque d'exemples concrets
(…)
- 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é
Comme souvent dans les documentations les cas d'exemple manquent effectivement. Depuis que je suis ce fil, j'ai fait quelques recherches pour en savoir un peu plus sur le sujet, en me demandant tout du long à quels cas d'exemples concrets des restrictions peuvent être mises sur des applications, disons, dans des systèmes *nix ?
Aussi, ici : https://gitlab.com/apparmor/apparmor/-/wikis/GettingStarted
comme dans de nombreuses docs en ligne…
Alors en plus des CMS, quelles applications valent, selon vous, d'être l'objet de limites ? Avez-vous quelques autres exemples concrets ?
Merci par avance, Joyce MARKOLL
Je me permet juste de revenir sur ce point: l'activation d'apparmor reste conditionné par la présence du package adhoc, lequel n'est pas installé sur une netinstall par exemple
/me flies away
On 1/19/20 1:16 PM, contact@orditux.org wrote:
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.
(…)
On Sun, 19 Jan 2020 13:22:05 +0100 frsag@jack.fr.eu.org wrote:
Je me permet juste de revenir sur ce point: l'activation d'apparmor reste conditionné par la présence du package adhoc, lequel n'est pas installé sur une netinstall par exemple
/me flies away
"apt-cache policy <nom du paquet>" (sans les guillemets) le dira à tout sysadmin (qui connaît *forcément* ses bases). Cela dit, tu aurais pu répondre au message initial (et en dessous), et non à mon message, ta réponse n'ayant rien à voir avec ma question.
Cordialement, Joyce MARKOLL
Hello la liste,
Alors personnellement, j'utilise exclusivement SELinux.
Il n'est pas si difficile d'écrire les règles surtout si on utilise le CIL au lieu du M4+compilation.
Pour ce qui de quelle application devrait être en enforced, je réponds simplement toutes.
C'est tout le système qui devrait l'être et pas de passe-droit.
Les containers sont strictement confinés à eux seul, idem pour les microservices ou app. Pourquoi une webapp serait autorisée à sortir de son emplacement d'installation?
Identique pour les applications, si on veut autoriser l'application à accéder au dossier documents qu'on a fait pour elle, on set le context/group et comme quoi cette application a ce droit et uniquement celui-ci.
Cela force à savoir comment fonctionne les applications qu'on utilise mais est-ce un mal en soi ?
Dois-je rapeller qu'il y a encore des développeurs qui essaient d'accéder à la zone mémoire 0 ? Comment empêchez vous cela sans utiliser un système comme SELinux ?
La vraie bonne question est: voulez-vous un contrôle et connaissance parfaite de votre parc?
Excellente journée
On Sun, Jan 19, 2020, 08:55 contact@orditux.org wrote:
On Sun, 19 Jan 2020 13:22:05 +0100 frsag@jack.fr.eu.org wrote:
Je me permet juste de revenir sur ce point: l'activation d'apparmor reste conditionné par la présence du package adhoc, lequel n'est pas installé sur une netinstall par exemple
/me flies away
"apt-cache policy <nom du paquet>" (sans les guillemets) le dira à tout sysadmin (qui connaît *forcément* ses bases). Cela dit, tu aurais pu répondre au message initial (et en dessous), et non à mon message, ta réponse n'ayant rien à voir avec ma question.
Cordialement, Joyce MARKOLL
-- Orditux Informatique https://orditux.org https://orditux.org/aol _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonsoir,
On Sunday 19 January 2020 13:16:21 contact@orditux.org wrote:
j'ajoute une question à la fin de ce mail, sans que cela soit forcément pour un usage prochain (pour ma culture générale).
...
- 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é
Comme souvent dans les documentations les cas d'exemple manquent effectivement. Depuis que je suis ce fil, j'ai fait quelques recherches pour en savoir un peu plus sur le sujet, en me demandant tout du long à quels cas d'exemples concrets des restrictions peuvent être mises sur des applications, disons, dans des systèmes *nix ?
Avec apparmor, principalement les droits sur les fichiers (rwx), en complément des droits unix. On peut également gérer les capabilities (man 7 capabilities), quels signaux peuvent être envoyés et a qui, et quelques autres droits plus obscurs (droits mount, ptrace, ...). Les droits d'accès au réseau ne sont pas dispo sous debian (pas dans le noyau vanilla).
Avec selinux, c'est beaucoup plus bas niveau et aussi plus précis. On peut gérer les syscalls un par un.
Aussi, ici : https://gitlab.com/apparmor/apparmor/-/wikis/GettingStarted
comme dans de nombreuses docs en ligne…
Alors en plus des CMS, quelles applications valent, selon vous, d'être l'objet de limites ? Avez-vous quelques autres exemples concrets ?
Je dirais toutes. Sur un serveur, c'est faisable. Cependant, pour un poste de travail, vu la complexité pour les applications de bureau, partir sur les applications exposées au réseau me parait plus raisonnable.
Je n'ai personnellement pas d'autres exemples d'attaques évitées, mais je pense que les dernières failles exim auraient pu être atténuées grâce a une solution de MAC. Et bien sur c'est aussi utile pour les webapp mal codées
-
contact＠orditux.org -
Florent CARRÉ -
frsag＠jack.fr.eu.org -
Jonathan Leroy - Inikup -
Vincent Tondellier