Changement du mode de distribution du code source de RHEL par Red Hat
- En juin 2023, Red Hat a pris la décision controversée de modifier la manière dont est distribué le code source derrière Red Hat Enterprise Linux (RHEL)
- Cette décision a soulevé de nombreuses questions sur la viabilité future des reconstructions en aval de RHEL, comme Rocky Linux, AlmaLinux et Oracle Linux
- Chaque distribution a ensuite publié une annonce pour rassurer sa communauté
- Dans de nombreuses communautés open source, la décision de Red Hat a été interprétée comme l’influence d’une entreprise avide
- Certains disent qu’ils ont migré ou qu’ils migrent vers Debian, à la recherche d’un refuge
Importance et difficulté de la sécurité
- La sécurité est difficile, ennuyeuse, désagréable, et demande beaucoup d’efforts si l’on veut bien faire les choses
- Debian ne fait pas suffisamment d’efforts pour protéger ses utilisateurs
Adoption de SELinux par Red Hat et fourniture de politiques par défaut
- Red Hat a adopté SELinux depuis longtemps, et est allé bien au-delà de la simple activation de la fonctionnalité dans le noyau
- L’entreprise a accompli le travail difficile de créer des politiques SELinux par défaut pour sa distribution
- Ces politiques sont activées par défaut dans RHEL et contribuent à protéger de nombreux démons et serveurs couramment exécutés par défaut sur RHEL
- Apache, nginx, MariaDB, PostgreSQL, OpenSSH et d’autres sont tous protégés par les politiques SELinux fournies dans la distribution RHEL
Application des politiques SELinux aux conteneurs
- Cette protection s’étend aussi aux conteneurs
- Les conteneurs deviennent une méthode de plus en plus privilégiée par les développeurs pour déployer des logiciels
- Penser qu’exécuter quelque chose dans un conteneur est intrinsèquement sûr est une idée fausse
- Les conteneurs ne résolvent pas les problèmes de sécurité eux-mêmes ; ils résolvent des problèmes de déploiement logiciel
- Sur les distributions basées sur Red Hat, il est possible d’utiliser podman, une alternative à Docker qui permet d’exécuter des conteneurs sans daemon et de manière totalement rootless
- Red Hat va plus loin en appliquant des politiques SELinux par défaut robustes qui isolent les conteneurs du système hôte et des autres conteneurs
- L’application des politiques SELinux aux conteneurs fournit des garde-fous renforcés qui atténuent le risque de vulnérabilités futures encore inconnues
Les efforts de Red Hat pour fournir des politiques SELinux par défaut
- Red Hat savait que sans ce travail sur les politiques par défaut, les utilisateurs n’adopteraient pas la technologie et que des millions de serveurs resteraient vulnérables
- SELinux est difficile ; son langage de politique et ses outils sont complexes, obscurs, et à peu près aussi séduisants qu’une déclaration d’impôts
- Mais grâce au travail réalisé par Red Hat, l’usage de SELinux dans RHEL est en grande partie transparent et apporte de réels bénéfices de sécurité aux utilisateurs
L’approche de Debian avec AppArmor
- Debian est un pilier de la communauté open source, réputé pour sa stabilité et sa vaste bibliothèque logicielle
- Cependant, son framework de sécurité par défaut laisse encore beaucoup de place à l’amélioration
- La décision d’activer AppArmor par défaut à partir de Debian 10 est un pas positif pour améliorer la sécurité, mais sa mise en œuvre reste incomplète à l’échelle du système
- La dépendance de Debian à AppArmor et sa configuration par défaut montrent qu’il existe un problème structurel dans son approche de la sécurité
- AppArmor peut offrir une sécurité solide lorsqu’il est correctement configuré, mais les réglages par défaut de Debian n’exploitent pas son potentiel
Les problèmes d’AppArmor dans Debian
- Profils par défaut limités : Debian est livré avec un ensemble minimal de profils AppArmor, ce qui laisse de nombreux services critiques sans protection
- Approche réactive plutôt que proactive : le modèle de sécurité de Debian repose souvent sur les utilisateurs pour mettre en œuvre des politiques plus strictes, au lieu de fournir par défaut une configuration sûre
- Application incohérente : contrairement à SELinux sur les systèmes Red Hat, AppArmor sur Debian n’est appliqué que partiellement, ce qui crée des failles de sécurité potentielles
- Manque de ressources : en tant que projet centré sur la communauté, Debian ne dispose pas des ressources nécessaires pour développer et maintenir des politiques de sécurité aussi complètes que celles fournies par Red Hat
Exécution de charges de travail conteneurisées avec Docker sur Debian
- Exécuter des charges de travail conteneurisées via Docker sur Debian est extrêmement courant
- Docker génère et charge automatiquement un profil AppArmor par défaut pour les conteneurs, appelé
docker-default
- Malheureusement, ce profil n’est pas particulièrement robuste du point de vue de la sécurité et il est excessivement permissif
- Ce profil offre un certain niveau de protection, mais laisse exposée une surface d’attaque importante
Différences fondamentales entre AppArmor et SELinux
- La différence fondamentale entre AppArmor et SELinux réside dans leur approche du contrôle d’accès obligatoire (MAC)
- AppArmor fonctionne selon un modèle fondé sur les chemins, tandis que SELinux utilise un système d’application par types bien plus complexe
- Ces différences sont particulièrement marquées dans les environnements de conteneurs
- SELinux applique des types à tous les objets du système (fichiers, processus, ports, etc.)
- Lorsqu’un conteneur est lancé sur un système RHEL avec prise en charge de SELinux, il reçoit immédiatement le type
container_t, un mécanisme de contrôle d’accès strict
- Le type
container_t cloisonne efficacement le conteneur, l’empêchant d’interagir avec des objets qui n’ont pas été explicitement étiquetés pour un usage conteneurisé
- SELinux ne s’arrête pas à l’application par types et pousse l’isolation des conteneurs encore plus loin grâce aux labels de sécurité multi-catégories (MCS)
- Ces labels servent de couche de séparation supplémentaire, maintenant l’isolation même entre des conteneurs du même type (
container_t)
- Chaque conteneur reçoit son propre label MCS, créant une sandbox privée à l’intérieur de l’environnement plus large
container_t
L’approche d’AppArmor
- AppArmor ne se préoccupe ni des types ni des catégories et se concentre sur la limitation des capacités de programmes spécifiques à partir de profils prédéfinis
- Ces profils définissent les fichiers auxquels un programme peut accéder et les opérations qu’il peut effectuer
- Cette approche est plus simple à mettre en œuvre et à comprendre, mais elle est moins fine et moins cohérente à l’échelle du système que l’application par types de SELinux
- Les distributions Linux grand public ne déploient pas par défaut de profils AppArmor complets pour tous les démons réseau courants
Impact concret
- Dans un environnement SELinux, un conteneur compromis se heurte à des obstacles majeurs pour accéder au système hôte ou à d’autres conteneurs, ou pour les affecter, grâce à la double barrière de l’application par types et des labels MCS
- SELinux offre une isolation plus forte, mais au prix d’une complexité accrue et d’un possible surcoût en performance
- AppArmor propose un modèle de sécurité plus simple et plus accessible, qui peut néanmoins rester très efficace lorsqu’il est correctement configuré
- Red Hat a fait les efforts nécessaires pour rendre l’usage conjoint de SELinux et des conteneurs fluide et simple
- En fin de compte, le choix entre Debian et Red Hat ne se résume pas à un choix entre influence des entreprises et développement communautaire
- C’est aussi un choix entre un système qui suppose le meilleur et un système qui se prépare au pire
- Dans le monde hautement connecté d’aujourd’hui, le pessimisme est malheureusement indispensable
L’avis de GN⁺
- Le changement de politique de Red Hat concernant la distribution du code source de RHEL est controversé, mais du point de vue de la sécurité, il peut être considéré comme rationnel
- Dans les distributions Linux d’entreprise, il est essentiel de fournir des fonctions de sécurité robustes comme SELinux
- Cependant, ce changement de politique de Red Hat pourrait avoir un impact négatif sur l’écosystème open source, et le rôle des distributions communautaires comme Debian pourrait devenir encore plus important
- Debian est connue comme une distribution conviviale et flexible, mais elle a besoin de renforcer ses fonctions de sécurité par défaut
- AppArmor n’est pas aussi puissant que SELinux, mais il peut constituer une solution de sécurité efficace s’il est correctement configuré
- À long terme, il pourrait être nécessaire de développer un nouveau framework de sécurité combinant les avantages de SELinux et d’AppArmor
- La sécurité des conteneurs est un enjeu crucial à l’ère du cloud native ; toutes les distributions devraient donc consacrer davantage d’efforts à ce sujet
2 commentaires
Il est vrai qu’AppArmor est moins strict que SELinux..
mais il est difficile de dire pour autant que sa sécurité est faible.
SELinux est tellement strict que, lorsqu’on configure un serveur, on finit presque toujours par le désactiver.
Et sur desktop, la sécurité n’est pas la préoccupation principale de SELinux.
Il faut des restrictions nécessaires du point de vue de l’interface et de l’expérience utilisateur, ainsi que des procédures appropriées de demande d’authentification, et c’est une problématique différente de l’isolation des ressources comme avec SELinux.
C’est pourquoi, pour la sécurité desktop, qu’il s’agisse de la famille Red Hat ou de la famille Debian, tout repose sur polkit (PolicyKit), standardisé par freedesktop.
Avis Hacker News