En même temps, faut pas se voiler la face. AppArmor a failli disparaitre sans Canonical qui voulait avoir une alternative à SELinux, car Novell avait finalement décidé de lacher l'affaire. At AppArmor est en retard niveau intégration partout ailleurs, car Canonical n'a pas vraiment les ressources.
Pr exemple, dbus a d'abord supporté SELinux, puis AppArmor. Postgresql supporte la séparation par SELinux, pas par AppArmor. Des distros comme Gentoo, Debian ou Fedora ont supportés SELinux bien en premier, puis vaguement Apparmor. Les seuls à avoir AppArmor de base sont celles ou le sponsor a décidé d'en haut de pousser la techno, ie Ubuntu et Opensuse. IE, la communauté poussant AppArmor est pas très grande.
Et je peux détailler en long, en large et en travers pourquoi à mon sens AppArmor est plus primitif et moins extensible que SELinux.
Par exemple, AppArmor utilise des chemins pour les permissions et les accès la ou SELinux rajoute une couche d'indirection, ce qui le rends impropre a un usage comme "ce document est noté top secret, personne doit le lire". Apparmor ne supporte pas trop le concept de MLS ( mais sur la TODO list http://wiki.apparmor.net/index.php/AppArmorMLS ). Et c'est pas un exemple purement théorique non utilisé en pratique, car tout openshift dépend de ça pour l'isolation des gens.
Autre example, changer le repertoire racine d'un serveur web. Sous SELinux, tu changes le label du répertoire via semanage fcontext, et voila. Sous AppArmor avec le système de profile, tu doit modifier tout les profiles pour copier les permissions. Mais donc du coup, pour palier à ce cas, ils ont rajouté le concept d'alias. Donc tu va dire que /var/www/ est un alias vers /home/www et donc que les accès de l'un correspondent aux accès de l'autre. Donc la ou une solution élégante est en place, on rajoute un truc de plus.
Je pourrais dire comment les politiques de sécurité SELinux sont configurable via des booleans, etc, etc. Et comment la config de apparmor, c'est juste des variables prédéfinis. En théorie, on peut faire la même chose avec AppArmor, sauf qu'en pratique, c'est quasiment du tout ou rien.
Je pourrait rajouter comment le fait de rajouter un nouveau type d'objet ( genre les sockets réseau ) implique de rajouter une option au parser, des nouveaux types d'objet dans la lib et de tout recompiler, la ou SELinux fait ça de façon indépendante du code dans le kernel et le reste, tout dans sa policy ( et avec du code pour l'arbitrage dans le programme qui va se servir de la policy, bien sur ). Comprendre comment faire ça, c'est globalement un workshop de 2h pour quelqu'un qui sait écrire une policy.
Alors ouais, SELinux semble s'avancer pour devenir quasiment un choix "normaliser" ( mais ça reste plus que relatif, car le défaut pour la majorité des distros, ça va surtout être "rien" ). Mais c'est surtout que ç'est plus extensible, ce qui permet de faire plus de choses, ce qui fait qu'il y a un marché pour ça, et donc des investissements.
[^] # Re: Politique
Posté par Misc (site web personnel) . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 8.
En même temps, faut pas se voiler la face. AppArmor a failli disparaitre sans Canonical qui voulait avoir une alternative à SELinux, car Novell avait finalement décidé de lacher l'affaire. At AppArmor est en retard niveau intégration partout ailleurs, car Canonical n'a pas vraiment les ressources.
Pr exemple, dbus a d'abord supporté SELinux, puis AppArmor. Postgresql supporte la séparation par SELinux, pas par AppArmor. Des distros comme Gentoo, Debian ou Fedora ont supportés SELinux bien en premier, puis vaguement Apparmor. Les seuls à avoir AppArmor de base sont celles ou le sponsor a décidé d'en haut de pousser la techno, ie Ubuntu et Opensuse. IE, la communauté poussant AppArmor est pas très grande.
Et je peux détailler en long, en large et en travers pourquoi à mon sens AppArmor est plus primitif et moins extensible que SELinux.
Par exemple, AppArmor utilise des chemins pour les permissions et les accès la ou SELinux rajoute une couche d'indirection, ce qui le rends impropre a un usage comme "ce document est noté top secret, personne doit le lire". Apparmor ne supporte pas trop le concept de MLS ( mais sur la TODO list http://wiki.apparmor.net/index.php/AppArmorMLS ). Et c'est pas un exemple purement théorique non utilisé en pratique, car tout openshift dépend de ça pour l'isolation des gens.
Autre example, changer le repertoire racine d'un serveur web. Sous SELinux, tu changes le label du répertoire via semanage fcontext, et voila. Sous AppArmor avec le système de profile, tu doit modifier tout les profiles pour copier les permissions. Mais donc du coup, pour palier à ce cas, ils ont rajouté le concept d'alias. Donc tu va dire que /var/www/ est un alias vers /home/www et donc que les accès de l'un correspondent aux accès de l'autre. Donc la ou une solution élégante est en place, on rajoute un truc de plus.
Je pourrais dire comment les politiques de sécurité SELinux sont configurable via des booleans, etc, etc. Et comment la config de apparmor, c'est juste des variables prédéfinis. En théorie, on peut faire la même chose avec AppArmor, sauf qu'en pratique, c'est quasiment du tout ou rien.
Je pourrait rajouter comment le fait de rajouter un nouveau type d'objet ( genre les sockets réseau ) implique de rajouter une option au parser, des nouveaux types d'objet dans la lib et de tout recompiler, la ou SELinux fait ça de façon indépendante du code dans le kernel et le reste, tout dans sa policy ( et avec du code pour l'arbitrage dans le programme qui va se servir de la policy, bien sur ). Comprendre comment faire ça, c'est globalement un workshop de 2h pour quelqu'un qui sait écrire une policy.
Alors ouais, SELinux semble s'avancer pour devenir quasiment un choix "normaliser" ( mais ça reste plus que relatif, car le défaut pour la majorité des distros, ça va surtout être "rien" ). Mais c'est surtout que ç'est plus extensible, ce qui permet de faire plus de choses, ce qui fait qu'il y a un marché pour ça, et donc des investissements.