Journal Choisir un module de sécurité linux

Posté par  . Licence CC By‑SA.
Étiquettes :
13
25
oct.
2011

À titre personnel, j'ai envie de découvrir un peu le monde des LSM.

Je ne suis pas vraiment parano mais leurs possibilités me semblent intéressantes. La question c'est : lequel choisir ?

Il y en a 4 qui ont chacun leurs avantages :

SELinux

C'est le plus vieux et le mieux intégré (la plupart des distributions proposent en standard une version de coreutils adaptée), mais il est basé sur des attributs de fichiers, ce qui empêche de s'en servir sur n'importe quel système de fichier (tmpfs a était modifié récemment en ce sens) donc pas sur les clef USB en FAT32. Il est aussi réputé complexe à prendre en main.

SMACK

Il est plus simple que SELinux mais pose le même problème pour les systèmes de fichiers.

AppArmor

Lui est assez éprouvé, ne repose pas sur des attributs de fichiers et possède un mode d'apprentissage agréable (on crée les règles, mais elles lèvent simplement des alertes au lieux de bloquer (je ne sais pas si les autres possèdent ce genre de possibilité)), mais je ne sais pas que dire de la pérennité de la solution vu qu'il a changé de main déjà deux fois.

TOMOYO

Lui non plus ne se base pas sur les attributs des fichiers, le projet semble très actif. Mais je connais mal ses possibilités.

Vous, utilisez-vous un LSM ? Avez-vous des conseil à donner ?

  • # SELinux

    Posté par  (site web personnel) . Évalué à 8.

    SELinux propose un mode permissif où il ne bloque rien: setenforce Permissive pour l'activer.

  • # TOMOYO

    Posté par  (site web personnel) . Évalué à 6. Dernière modification le 25 octobre 2011 à 13:23.

    Pour TOMOYO il y a des live-CD et des tutos très bien foutus qui permettent de jouer avec pour voir à quoi ça ressemble.

    Tutorial d'utilisation du Live-CD Ubuntu 10.04 : http://tomoyo.sourceforge.jp/1.8/ubuntu10.04-live.html.en
    Tutorial d'utilisation du Live-CD CentOS 6 : http://tomoyo.sourceforge.jp/1.8/centos6-live.html.en

    Un volontaire pour écrire une dépêche sur l'utilisation de ce module ? Avec le live-CD cela devrait être assez simple.

    • [^] # Re: TOMOYO

      Posté par  (site web personnel) . Évalué à 4.

      ou alors il nous faudrait des dépêches à la AskSlashdot^WAskLinuxFr ;-) (en complément des « Petites Brèves » par exemple).

    • [^] # Re: TOMOYO

      Posté par  . Évalué à 3.

      Je regarderais ça avant toute chose je pense. La possibilité de ne pas modifier mon système me plaît. Mais je passerais de toute manière sur mon installation à moi pour voir ce que ça donne dans la vrai vie avec plusieurs semaines d'utilisation.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: TOMOYO

      Posté par  . Évalué à 2.

      Lui non plus ne se base pas sur les attributs des fichiers

      Je ne connais pas TOMOYO, mais dans la dépêche sur la sortie du noyau Linux 3.1, il était précisé qu'il intègre maintenant une gestion d'ACL.
      Est-ce que ça le rapproche du fonctionnement de SELinux ?

  • # Précision sur selinux

    Posté par  (site web personnel) . Évalué à 10.

    Alors pour répondre tout d'abord à la question, j'utilise SElinux.

    Et pour compléter, SElinux est aussi intégré dans postgresql et dans iptables ( pour dire "tel process a accès à tel base, ou tel régle de firewall s'applique" ). Quand à la complexité, c'est une affirmation qu'on retrouve souvent, surtout de la part des codeurs d'apparmor. Tout comme un firewall pour 4000 machines et des 100aines de vlans va être horriblement complexe, une politique SElinux exhaustive a beaucoup de règles. Et ce qui sauvent les autres de la critique de la complexité, c'est surtout le fait qu'aucune politique de sécurité aussi complète n'existe notament pour apparmor. j'ai regardé le nombre de reglé sur une Ubuntu Lucid, c'est assez .

    SElinux s'appuie sur les attributs étendus, tout comme les acl posix ou d'autres choses. Certes, ça rends les clés fat vachement moins utiles mais que demander à un système de fichier qui ne gère pas les permissions tout court. Tu peux néanmoins appliquer un label global pour tout le FS, tout comme tu peux donner tout à un utilisateur. Et le souci se pose plus pour nfs ( malgré le projet http://selinuxproject.org/page/Labeled_NFS ) que pour les clés usb.

    Le système est très documenté sur tout un tas de distribution ( Debian, Gentoo, Fedora ), est mis par défaut sur Fedora et RHEL. Un lien récent regroupe les différentes documentations existantes ( https://www.wzdftpd.net/blog/index.php?tag/selinux ), pour les gens qui veulent se documenter.

    Et je pense que depuis le temps, les coreutils sont de base avec selinux, pas besoin de modification ( autre que "rajouter --enable-selinux" ).

    Et sinon, les policys selinux, c'est du m4. J'ai mis une soirée à écrire ma première policy, donc c'est pas si dur que ça.

    Et pour les conseils, je te propose de plutôt commencer par te demander ce que tu veux faire pour déterminer ensuite celui qui va répondre à ton besoin.

    • [^] # Re: Précision sur selinux

      Posté par  . Évalué à 3.

      Merci beaucoup pour ton retour avisé.

      Et pour compléter, SElinux est aussi intégré dans postgresql et dans iptables ( pour dire "tel process a accès à tel base, ou tel régle de firewall s'applique" ). Quand à la complexité, c'est une affirmation qu'on retrouve souvent, surtout de la part des codeurs d'apparmor. Tout comme un firewall pour 4000 machines et des 100aines de vlans va être horriblement complexe, une politique SElinux exhaustive a beaucoup de règles. Et ce qui sauvent les autres de la critique de la complexité, c'est surtout le fait qu'aucune politique de sécurité aussi complète n'existe notament pour apparmor. j'ai regardé le nombre de reglé sur une Ubuntu Lucid, c'est assez.

      Je pense que la maturité de l'intégration et la quantité de documentation limitent de toute manière la complexité.

      SElinux s'appuie sur les attributs étendus, tout comme les acl posix ou d'autres choses. Certes, ça rends les clés fat vachement moins utiles mais que demander à un système de fichier qui ne gère pas les permissions tout court. Tu peux néanmoins appliquer un label global pour tout le FS, tout comme tu peux donner tout à un utilisateur.

      Ca me serait suffisant l'idée étant surtout de gérer les droits sur l'ensemble du périphérique.

      Et le souci se pose plus pour nfs ( malgré le projet http://selinuxproject.org/page/Labeled_NFS ) que pour les clés usb.

      J'utilise pas NFS, c'est pour ça que j'en ai pas parlé.

      Et pour les conseils, je te propose de plutôt commencer par te demander ce que tu veux faire pour déterminer ensuite celui qui va répondre à ton besoin.

      Je ne connais même pas l'ensemble des possibilités de ce genre de modules. Ce sera pour une utilisation sur ma machine de bureau, je présume que je vais commencer par bidouiller avec une arborescence juste faites pour voir ce que je peux changer comme droits, etc. Puis j'irais bidouiller mon système (en essayant de ne pas le détruire au passage).

      Comme c'est plus pour explorer que pour une utilisation sur serveur en production, j'aurais du mal à définir mes besoins.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Précision sur selinux

      Posté par  . Évalué à 2.

      Comment se passe une éventuelle sauvegarde ? On sauvegarde les règles en même temps que le système de fichier ou on peut le faire différemment pour par exemple déployer sur une nouvelle installation ?

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Précision sur selinux

        Posté par  (site web personnel) . Évalué à 3.

        Dans le cas de selinux, les règles sont sous formes d'un fichier compilé ( extension .pp ), et sinon, tu as 3 ( ou plus ) fichiers pour décrire la policy.

        Pour les labels, il faut avoir tar ou autre qui supporte les attributs étendus.

  • # Grsecurity

    Posté par  . Évalué à 4.

    Pas vraiment LSM car n'utilise pas l'infrastructure du noyau, mais il propose les mêmes fonctionnalités et d'autres (il intègre pax).
    Je l'ai utilisé sur de nombreux serveurs et l'utilise encore (activation de toutes les protections sauf RBAC) sur ceux qu'il me reste, et j'en suis content.
    Je pense qu'il a sa place à coté des outils cités si l'on ne se limite pas aux systèmes 'LSM'.

    • [^] # Re: Grsecurity

      Posté par  . Évalué à 1.

      Je suis également assez fan de grsecurity, émulation NX, pas mal de sécurisations du kernel, chroot, etc.

  • # comparaison

    Posté par  (site web personnel) . Évalué à 6.

    J'ai essayé SELinux (sur fedora), AppArmor (sur ubuntu ?) et TOMOYO (sur mandriva). Voici mon avis

    • SELINUX : difficile à prendre en main sans investissement, l'administration ne me parait pas naturelle

    • AppArmor : j'aime bien : simple à administrer, efficace. J'ai laissé tomber car à un moment, il n'était plus vraiment maintenu.

    • TOMOYO : simple à utiliser et administrer, avec des notamment des interfaces curses bien faites : c'est mon préféré. On peut aussi scripter sans soucis. En plus, le projet est très actif et évolue rapidement.

    • [^] # Re: comparaison

      Posté par  (site web personnel) . Évalué à 4.

      Après une nuit de repos, voici quelques indications supplémentaires :

      TOMOYO a plusieurs modes (pour chaque règle) qui permettent une mise en oeuvre progressive:

      • "apprentissage" (learning) qui permet de générer les règles pour sa machine

      • "warning" (permissive) : prévient mais laisse faire si la règle n'existe pas

      • "securite" (enforcing) : prévient et bloque si la règle n'existe pas

      Je l'ai utilisé en exploitation pour sécuriser une machine en DMZ pendant plusieurs années. Cela demande un travail quotidien si les applications évoluent. Et il y a beaucoup de choses à reprendre quand on fait une montée d'OS (en gros repasser en mode apprentissage, et nettoyer les règles inutiles)

  • # Linux 3.1 et TOMOYO Linux 2.4

    Posté par  . Évalué à 5.

    La version 3.1 du noyau Linux propose des changements assez important dans TOMOYO Linux qui passe en 2.4. Ceux-ci sont suffisamment intéressants pour être disponibles en backport pour les noyaux antérieurs à partir du 2.6.33.

    Attention, les fichiers de configuration ne sont pas rétro-compatibles !

    la documentation
    les patchs

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.