Sondage Quel mécanisme de contrôle d'accès utilisez-vous pour votre système d'exploitation ?

Posté par . Licence CC by-sa
7
21
sept.
2014

Avant la conférence Kernel Recipes et la rédaction d'un article pour Linux Mag, j'aimerais lancer les questions suivantes : utilisez-vous un mécanisme de contrôle d'accès avec vos systèmes d'exploitation ? Si oui lequel ?

merci. Samir

  • SElinux :
    103
    (11.6 %)
  • AppArmor :
    79
    (8.9 %)
  • SMACK :
    0
    (0.0 %)
  • tomoyo :
    3
    (0.3 %)
  • yama :
    4
    (0.4 %)
  • capabilities :
    8
    (0.9 %)
  • grsecurity :
    13
    (1.5 %)
  • chroot :
    38
    (4.3 %)
  • aucun (ou le parefeu OpenOffice.org) :
    451
    (50.7 %)
  • geste de la main plus « ce n'est pas cet accès que vous cherchez » :
    155
    (17.4 %)
  • autre (en commentaire ) :
    35
    (3.9 %)

Total : 889 votes

La liste des options proposées est volontairement limitée : tout l'intérêt (ou son absence) de ce type de sondage réside dans le fait de forcer les participants à faire un choix. Les réponses multiples sont interdites pour les mêmes raisons. Il est donc inutile de se plaindre au sujet du faible nombre de réponses proposées, ou de l'impossibilité de choisir plusieurs réponses. 76,78% des sondés estiment que ces sondages sont ineptes.
  • # Aucun, et, à quoi ça sert

    Posté par . Évalué à 4.

    Je n'en utilise pas sur ma distrib (ou pas à ma connaissance).
    Sur Fedora, je désactive systématiquement SELinux.

    Je ne sais pas ce que ça peut apporter en plus, pour un ordinateur personnel.

    • [^] # Re: Aucun, et, à quoi ça sert

      Posté par (page perso) . Évalué à 4.

      Sur Fedora, je désactive systématiquement SELinux.

      Pareil et en plus je passe tout le disque en chmod 777 parce que je vois pas pourquoi j'aurais de problème, je sais ce que je fais.

      Et sinon en vrai sur ma Fedora je laisse SELinux et je fais les quelques réglages simples pour que ça tourne avec les services (vu que je m'autohéberge) que j'ai pourtant installés à des endroits parfois bizarres.

      • [^] # Re: Aucun, et, à quoi ça sert

        Posté par (page perso) . Évalué à 2.

        Pareil et en plus je passe tout le disque en chmod 777 parce que je vois pas pourquoi j'aurais de problème, je sais ce que je fais.

        J'avais fais pareil, mais ensuite, je n'étais aperçu de mon erreur.
        Heureusement, un petit # chmod -R -x /* a tout remis d'aplomb…

        Sed fugit interea, fugit inreparabile tempus, singula dum capti circumvectamur amore

    • [^] # Re: Aucun, et, à quoi ça sert

      Posté par (page perso) . Évalué à 6.

      Si c'est bien configuré, ça évite les comportements suspects. Par exemple, un mail forgé pour profiter d'un buffer overflow et lire tes cookies dlfp pour pouvoir poster sous ton nom peut être éviter. (ou ajouter un PATH=~/.malwaredir/:$PATH dans le bahrc).

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Aucun, et, à quoi ça sert

      Posté par . Évalué à 0.

      Non, je ne mets pas de chmod 777; il ne faut pas être mazo non plus.

      Néanmoins, tout fonctionne sans soucis et les permissions de base sont suffisantes pour un PC (je ne parle pas de serveur)

      • [^] # Re: Aucun, et, à quoi ça sert

        Posté par (page perso) . Évalué à 6. Dernière modification le 21/09/14 à 21:41.

        Ben, franchement, j’ai rien non plus mais je commence à me demander sérieusement si ce n’est pas une erreur de ne rien mettre. Et à plus forte raison sur des serveurs (bon alors mon problème supplémentaire est qu’en utilisant des conteneurs, c’est un poil plus compliqué et je n’ai pas le temps d’arracher ce poil… donc…).

        Je ne sais pas si c’est possible (a priori ça devrait l’être, sinon quel intérêt…) mais j’aimerais beaucoup que personne sauf Firefox ne puisse lire la base de ses propres mots de passes, qu’aucune autre extension ne puisse s’installer ni se modifier, par exemple, ou les cookies.

        Pareil pour mes clefs SSH, pour le $PATH, pour les clefs GPG et j’en passe et des meilleurs.

        Les permissions UNIX de base, c’est bien, mais je ne crois vraiment pas que cela suffise, en aucun contexte : le nombre d’applications externes pouvant être installées (et je met NoScript dans le lot, hein) est trop important pour laisser ça au hasard.

        Love – bépo

      • [^] # Re: Aucun, et, à quoi ça sert

        Posté par (page perso) . Évalué à 7.

        Néanmoins, tout fonctionne sans soucis et les permissions de base sont suffisantes pour un PC (je ne parle pas de serveur)

        Et bien cette idée que "tout fonctionne sans souci" est quasiment parfaitement applicable à SELinux (surtout sur un ordi non serveur).

        Ca fait quand même des années que les politiques par défaut SELinux ont été raffinées (notamment par Fedora) et tant que tu restes sur les installations standard (même pour des services "serveur") tout est configuré comme il faut. Si comme moi tu installes par exemple postgresql en le configurant pour mettre sa BDD sur un point de montage sur mon raid au lieu de l'emplacement par défaut… bah c'est une ligne de config SELinux pour mettre le label qu'il faut sur le nouvel emplacement. Assez surmontable.

        Et pour répondre à Leryan c'est précisement à ça (entre autres sans doute ; je ne suis qu'un newbie SELinux) que ça sert : en gros tu mets sur ~/mozilla un label spécial, auquel tu ne donnes l'accès qu'au binaire firefox qui aura le même label, et même un malware sur lequel tu doubles-cliques ne pourra pas y accéder.

        • [^] # Re: Aucun, et, à quoi ça sert

          Posté par . Évalué à 3. Dernière modification le 23/09/14 à 16:08.

          Et qu'est-ce qui empêche un malware sur lequel tu doubles-clickes de s'ajouter ce label? (c'est une vraie question, j'avoue ne m'être jamais intéressé à ce genre de trucs…)

          • [^] # Re: Aucun, et, à quoi ça sert

            Posté par (page perso) . Évalué à 4.

            Normalement il n'a aps le label permettant d'effectuer une telle action, et il faut également les droits root.
            Après si tu lui donnes tous les pouvoirs pour qu'il contourne la protection, à ce niveau là on ne peut plus y faire grande chose.

            • [^] # Re: Aucun, et, à quoi ça sert

              Posté par . Évalué à 2.

              Donc, quand d'habitude on fait un simple chmod +x foo.sh, avec SELinux, il y à d'autres actions à faire, sans quoi rien ne peut se lancer?
              Ou est-ce que, par défaut, un certain niveau de "partage" est activé? Parce que sinon pour le dev/scripting ça doit être assez pénible… non?

              • [^] # Re: Aucun, et, à quoi ça sert

                Posté par (page perso) . Évalué à 3.

                Non, c'est juste que certains processus seulement ont l'autorisation de modifier les labels de SELinux. Donc le binaire téléchargé sur warez.com pourra par défaut faire des choses basiques mais s'il a besoin de ressources protégées par SELinux là il va falloir lui donner une politique adéquat. Et en l'occurence, il ne pourra pas dire à SELinux "coucou, je suis sûr, je te demande expressément de modifier mes labels pour pouvoir te contourner".

                • [^] # Re: Aucun, et, à quoi ça sert

                  Posté par . Évalué à 2.

                  Ok je vois. Donc on ne ferme l'accès qu'à des ressources précisées explicitement. Me reste à comprendre comment ça marche mais pour ça je ne connais qu'une solution… va falloir que je teste :)

              • [^] # Re: Aucun, et, à quoi ça sert

                Posté par . Évalué à 3.

                Donc, quand d'habitude on fait un simple chmod +x foo.sh, avec SELinux, il y à d'autres actions à faire, sans quoi rien ne peut se lancer?
                Ou est-ce que, par défaut, un certain niveau de "partage" est activé? Parce que sinon pour le dev/scripting ça doit être assez pénible… non?

                Generalement, l'utilisateur classique tourne dans le contexte "unconfined", ce qui lui donne à peu près toutes les permissions (comme si selinux n'était pas la), et il n'y a que les services qui sont limités par selinux.

    • [^] # Re: Aucun, et, à quoi ça sert

      Posté par (page perso) . Évalué à 10.

      Sur RHEL 7/Centos 7 et fedora je sais pas combien, les plugins firefox sont restreint via SELinux. Donc si jamais quelqu'un arrive à trouver une faille dans flash et la distribue via un réseau de pub, comme ça arrive souvent, ta clé ssh se fera pas faucher, sauf à contourner SElinux.
      ( tu peux aussi remplacer "clé ssh" par "fichier de mot de passe firefox" ).

      Il me semble aussi qu'il y a eu des choses sur les outils qui font des vignettes, au cas ou tu trouves une clé usb avec un fichier vérolé qui fait planter l'outil de vignette.

      Cf https://danwalsh.livejournal.com/54092.html

      Je pense aussi que SElinux permet de s'assurer que le compte guest ( paquet xguest ) est vraiment limité, ce qui sert sur un kiosque.

      Il permet également de limiter docker, qui est un outil assez à la mode en ce moment pour les devs ( donc sur un pc personnel ), et je suppose que selinux serviras aussi pour limiter les applications tierces pour ce que Gnome veut faire avec les histoires de sandbox.

    • [^] # Re: Aucun, et, à quoi ça sert

      Posté par . Évalué à 8.

      Ca peut permettre d'éviter que Skype n'aille regarder ton historique de Firefox, par exemple. Et ne l'envoie sous forme chiffrée à Microsoft.

      Une piste à suivre : http://www.debian-fr.org/securiser-skype-t41130.html

      Après vous en faites ce que vous voulez…

      Les contrôles d'accès permettent de s'assurer qu'un processus (donc un logiciel) n'accède pas à une information à laquelle il ne devrait normalement jamais accéder. Autrement dit, ça peut permettre d'éviter les attaques 0-day, les buffer overflows, ce genre de choses. Si demain Linux remplace Windows en parts de marché, les virus deviendront légion et les solutions de contrôle d'accès seront absolument indispensables.

      Ceci étant dit, j'ai recensé environ 1000 attaques sur le port SSH de mon serveur par jour (80 % en provenance de Chine). Pourtant il ne s'agit que d'une machine très banale, je n'ose pas imaginer sur un serveur critique. Donc je pense que n'importe quelle machine connectée à l'Internet devrait impérativement avoir une solution de contrôle d'accès.

      J'illustre à quoi ça peut servir concrètement : imagine qu'on découvre une faille jusque là totalement inconnue dans un logiciel de suivi d'activité de ton PC (faille 0-day) et que cette faille permet de récupérer tout tes fichiers perso. En l'occurrence, ce logiciel n'est pas censé accéder à tes fichiers perso puisqu'il n'en a pas besoin. Il a juste besoin d'accéder aux fichiers de suivi de température, au taux de charge de ta batterie, etc. Avec une solution de contrôle d'accès, tu écris une règle qui dit que ce logiciel ne devra jamais accéder à autre chose qu'aux fichiers système pour le suivi de la température et la charge de ta batterie. S'il essaie d'accéder à tes fichiers perso, il se fait jeter. Et donc la faille sera inefficace. Alors que sans contrôle d'accès, la faille devient utilisable et peut avoir des conséquences catastrophiques.

      Un contrôle d'accès permet même de restreindre les droits de root. Pensez-y, ça peut être très intéressant, car je ne vois pas pourquoi je dois accorder les pleins pouvoirs à Microsoft lorsque j'installe Skype sur mon ordi. Je veux juste installer Skype, pas formater mon disque dur, donc je ne vois pas trop pourquoi je donne le même niveau de droits à Microsoft qu'à moi-même. En réalité, root ne devrait quasiment jamais être utilisé, ou en tout cas pas à l'état pur. C'est un niveau de privilèges bien trop important pour ce qu'on souhaite généralement faire.

    • [^] # Re: Aucun, et, à quoi ça sert

      Posté par . Évalué à 2.

      Sur Fedora, je désactive systématiquement SELinux.

      Je ne sais pas ce que ça peut apporter en plus, pour un ordinateur personnel.

      Heu, sais-tu ce que ça t'apporte de le désactiver ?
      J'ai Fedora (ou RHEL) depuis de nombreuses années, avec SELinux, il est très très rare que j'ai à m'occuper de SELinux.

      • [^] # Re: Aucun, et, à quoi ça sert

        Posté par . Évalué à 1.

        Et bien, j'ai un LAMP pour faire 3 bricoles, et un petit samba pour partager des fichiers avec mon réseau local, et bien souvent, SELinux m'embête :)

      • [^] # Re: Aucun, et, à quoi ça sert

        Posté par . Évalué à 4.

        Heu, sais-tu ce que ça t'apporte de le désactiver ?

        Réponse courte:
        - du temps en plus pour faire des choses utiles,
        - des insatisfactions en moins.

        Réponse longue:
        Ça m'évite de passer des heures à pas comprendre pourquoi tel programme ne fonctionne pas et ne produit aucun message d'erreur clair sur le problème qu'il rencontre. Ce qui arrive souvent quand SELinux est activé et qu'on utilise autre chose que juste les packages Fedora/RHEL fournis avec la distrib et configuré comme testé par la distrib…

        • [^] # Re: Aucun, et, à quoi ça sert

          Posté par (page perso) . Évalué à 3.

          Faut pas déconner, depuis des années y a une notification graphique en cas de refus d'accès par SELinux, avec le détail et les infos sur quoi faire si on veut autoriser cet accès. Et si tu n'utilises pas d'environnement graphique, y a une alerte dans le fichier principal de log /var/log/messages avec également la marche à suivre pour rendre cet accès légal (et le détail brut dans /var/log/audit/audit.log au cas où). Alors bon moi aussi je peux démarrer un service sans rien lire ni avant (docs) ni après (logs), voir que ça marche pas comme je veux, et chier sur l'outil…

          • [^] # Re: Aucun, et, à quoi ça sert

            Posté par . Évalué à 1.

            Bah quand je code un programme qui se comporte comme s'il était buggué, je suis peut-être trop humble, mais je peux passer une heure à chercher le bug avant d'aller regarder dans /var/log/messages en me disant que c'est pas un bug mais cette merde infâme de SELinux.

            Donc je vais continuer à le désactiver et à chier dessus.

            Et à être incompris par les gens comme toi qui pensent qu'on ne fait que démarrer des services mais jamais les développer…

            Bisous.

  • # Les permissions Unix

    Posté par . Évalué à 10.

    Ça suffit bien !

  • # Virtualisation/isolation?

    Posté par (page perso) . Évalué à 2.

    Et la virtualisation kvm ou isolation comme lxc?

    Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

  • # choix par défaut

    Posté par . Évalué à 5.

    bah j'utilise apparmor par flemme de mettre autre chose sur ubuntu et que SELinux est une vrai usine à gaz…Mais bon, c'est pas pour ça que j'suis fan…

  • # Le mot de passe du BIOS

    Posté par (page perso) . Évalué à 1.

    J'utilise le mot de passe du BIOS comme mécanisme de contrôle d'accès pour ma distribution Linux. Et le reste en auto-login, ni de mot de passe de sortie de veille :-)

    Deux avantages :
    * En cas de vol, il y a de fortes chances que le voleur ne s'y connaisse pas suffisamment pour utiliser/revendre mon ordi
    * Le démarrage et l'utilisation est agréable avec un seul mot de passe depuis le démarrage

    Ah ! On me dit que arkhe parlait d'autre chose…

    Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)

    • [^] # Re: Le mot de passe du BIOS

      Posté par . Évalué à 1.

      En cas de vol, il y a de fortes chances que le voleur ne s'y connaisse pas suffisamment pour utiliser/revendre mon ordi

      Je ne vois pas en quoi c'est un avantage pour toi. Tu n'as plus ton PC, et il va finir à la poubelle, ce qui est a un coût écologique pour l'ensemble de la société. Si on me vole mon PC, je préfère que le voleur n'ait pas accès à mes données mais qu'il soit quand même capable de réutiliser mon PC.

      Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

      • [^] # Re: Le mot de passe du BIOS

        Posté par . Évalué à 1.

        Le must étant de pousser le dit voleur a re-connecter la machine a internet afin qu'on puisse le retrouver/recontrôler (via l'installation d'un logiciel espion/contrôle a distance).

      • [^] # Re: Le mot de passe du BIOS

        Posté par . Évalué à 3.

        Oui mais du coup, cela "incite" au vol.
        Alors que si tout les PC était inutilisable une fois volés (à la android/ios), les voleurs voleraient moins et ne seraient même plus des voleurs ,du coup !

        • [^] # Re: Le mot de passe du BIOS

          Posté par . Évalué à 1.

          Est-ce réellement faisable?

          Android et IOS ne sont pas protégé fasse au vol, il existe de nombreux outils pour flasher la rom (les mêmes outils pour rooter) et des outils pour changer les codes (IMEI etc), sans compter la flopée d'outils des services secrets.

          Je suis d'accord ces outils ne sont pas utilisable par le premier débile venu, se qui peut décourager les débiles de pratiquer le vol occasionnel, mais les réseaux organisé ne souffrent pas de ces problèmes. (d'après les docu les smartphones/pc sont envoyé en europe de l'Est où des ptits crack s'occupent de les dé-loocker).

  • # OpenBSD

    Posté par (page perso) . Évalué à 3.

    Sur mon serveur sous OpenBSD, j'ai rien à faire, et tout est chrooté :)

    • [^] # Re: OpenBSD

      Posté par . Évalué à 5.

      Chroot ne peux être considéré comme réel moyen d'isolation, il faut savoir que ce n'est pas du tout son rôle (qui est de pouvoir installer différents paquets/applications qui si elles étaient installées sur le même système rentrerais en conflit de dépendances..)
      Si un utilisateur malicieux arrive a obtenir un accès root a l’intérieur de la chroot, il lui suffit de créer une nouvelle chroot pour en sortir tout en gardant les privilèges root !

      C'est une très très grave erreur de considérer le chroot en tant que solution de sécurité, encore plus sur un serveur.

      • [^] # Re: OpenBSD

        Posté par (page perso) . Évalué à 4.

        Ce que tu écris est vrai, sauf la conclusion, parce-que

        Si un utilisateur malicieux arrive a obtenir un accès root a l’intérieur de la chroot

        ça fait quand-même un gros « si ». Un chroot réduit quand-même considérablement la surface d’attaque, parce-que trouver une faille dans un programme c’est une chose, mais l’exploiter ensuite pour trouver une faille dans le système qui permet de passer « root », ça fait une grosse marche supplémentaire. Et ça ce jeu là, on pourrait rajouter, exploiter une faille qui fait planter SELinux pour le même prix parce-que tous les mécanismes de contrôle contiennent des bugs, ça reste des logiciels.

        Donc chroot n’est pas la panacée, il faut savoir ce de quoi ça protège, mais c’est loin d’être nul comme en apport en matière de sécurité.

    • [^] # Re: OpenBSD

      Posté par . Évalué à 1.

      Pas mal ! Sous FreeBSD nous avons les jails :-P

  • # Ubuntu

    Posté par (page perso) . Évalué à 5.

    Le score d'apparmor me semble très faible dans le sondage. Sachant qu'Ubuntu est extrêmement utilisé et qu'apparmor est activé par défaut pour pleins de trucs sur cette distro, son score devrait être plus haut.
    Ou alors les utilisateurs d'Ubuntu désactivent apparmor ? Je n'y crois pas.

    • [^] # Re: Ubuntu

      Posté par . Évalué à 1.

      Anecdote avec AppArmor:
      J'ai voulu testé une installation de MySQL dans un container chiffré par truecrypt (ouvrable uniquement manuellement après démarrage du pc), AppArmor m'en a empêché :( (môsieur Armor ne comprenait rien au fait que le "disque" n'existe pas avant que je le monte avec truecrypt).
      Ptête que ça à changé, ou que c'est moi le noob (se qui est fort probable aussi ^ ^ ), mais c'était désagréable

    • [^] # Re: Ubuntu

      Posté par . Évalué à 10.

      Ou alors, ils ne savent pas qu'ils utilisent apparmor

      • [^] # Re: Ubuntu

        Posté par (page perso) . Évalué à 5.

        Possible. Probable même.

      • [^] # Re: Ubuntu

        Posté par . Évalué à 3.

        En effet, c'est mon cas.

      • [^] # Re: Ubuntu

        Posté par . Évalué à 7.

        Ou alors ils ne répondent pas aux sondages.

        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

        • [^] # Re: Ubuntu

          Posté par . Évalué à 3. Dernière modification le 22/09/14 à 13:44.

          Ou ils font comme moi, dans le doute il clique sur "aucun" ^ ^

          Avant de lancer le sondage, ça aurait été bien de faire un petit résumé du fonctionnement de ces outils :) (perso je n'aurais pas tenté le truc avec SQL je n'aurais probablement jamais entendu parler d'AppArmor).
          Les linuxiens sont curieux, mais linux est vaste, très vaste, énormément vaste ^ ^

  • # Divers...

    Posté par . Évalué à 2.

    Tournant surtout sous Ubuntu, c'est plutot du AppArmor, sinon quand il m'arrive de toucher a Gentoo, c'est du grsecurity mais ca prend 2/3 millions d'annees a configurer tout aux petits oignons (RBAC et co surtout…). En dernier lieu, pour le boulot, SELinux mais j'ai du mal a m'y faire …

  • # Une larteuse

    Posté par (page perso) . Évalué à 8.

    Larteuse

    * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

  • # grsecurity

    Posté par . Évalué à 10.

    Récemment j'ai ressenti le besoin de sécuriser un peu mon PC (et surtout l'envie d’expérimenter les divers solutions de sécurité existantes). Je ne suis pas du tout un expert dans le domaine, mais si ça intéresse quelqu'un voici ce que j'ai appris :

    SELinux, AppArmor, SMAK, Tomoyo
    Insuffisants. Ces solutions permettent de restreindre finement les droits des processus (plus finement qu'il n'est possible de le faire avec les permissions UNIX de base). Par exemple, comme mentionné dans un précédent commentaire, il est possible de les utiliser pour empêcher tout processus autre que firefox d’accéder aux données de ce dernier. Un malware s'exécutant sur la machine ne pourra donc pas récupérer les mots de passes stockés.

    C'est bien, mais ça ne suffit pas à assurer la protection d'une machine. Le problème c'est qu'un attaquant peut essayer de contourner ces protections en attaquant directement les processus ou le noyau (SELinux, AppArmor, SMAK et Tomoyo ne font absolument rien pour empêcher ça). Les failles dans le noyau ce n'est pas si rare que ça. Si un attaquant arrive à compromettre le noyau lui même alors c'est game over, il aura absolument tout pouvoir sur la machine.

    chroot
    Assez compliqué à mettre en place et pas très efficace. Encore une fois, même enfermé dans un chroot, un attaquant peut toujours s'en prendre directement au noyau. Mais même sans aller jusque là, suivant les droits dont il dispose, il peut faire pas mal de bêtises. Par exemple monter un système de fichier dans le chroot, créer des devices, s'attaquer aux IPC des autres applications. Et puis, depuis le chroot il a accès à l'interface réseau localhost aussi. Ça laisse pas mal de possibilités.

    Il y a des solutions plus poussées que le chroot pour isoler des processus. Je ne les ai pas testées alors je ne vais pas en parler. Mais d'après ce que j'ai pu lire à droite à gauche, il semblerait que le must de l'isolation reste la virtualisation avec Xen. Un jour il faudra que j'essaye.

    grsecurity
    La seule solution qui m'a convaincu jusqu'à maintenant. Grsecurity est en fait une colletions de plusieurs mécanismes de sécurité, chacun destiné à résoudre un problème précis. Il adresse le problème de la sécurité de façon plus globale que les solutions mentionnées ci-dessus.

    GRSecurity inclut un certain nombre de mécanismes pour protéger le noyau lui même. Ce n'est pas absolut, mais ça rend certaines failles non exploitables (ou plus difficiles à exploiter).

    GRSecurity fournit aussi RBAC, un équivalent de SELinux, AppArmor, SMAK et Tomoyo. Ce n'es qu'une opinion personnelle mais je le trouve beaucoup plus simple à utiliser. Par contre je n'ai pas obtenu de bon résultats avec le "mode apprentissage", j'ai dû faire toute ma config à la main, c'est un vrai jeu de patience. Après, rien n'empêche de désactiver RBAC et d'utiliser GRSecurity avec SELinux, AppArmor, SMAK ou Tomoyo à la place.

    Enfin GRSecurity fournit PAX, une solution destinée à empêcher l'exploitation des failles de type corruption de mémoire (buffer oveflow et autres) dans les processus fonctionnant sur la machine. PAX fonctionne en rendant aléatoire la disposition des données en mémoire et en rendant certaines zone mémoire non exécutables. Le noyau Linux de base fournit déjà des mécanismes similaires, PAX ne fait que les renforcer et les compléter. De même que RBAC, PAX demande pas mal de configuration car certaines applications (firefox, python, mono…) sont incompatibles avec certains mécanismes de protections (par exemple Python a besoin que sa pile soit exécutable). Encore un jeu de patience. Il faut aussi savoir que, pour qu'un processus puisse pleinement profiter de la protection offerte par le placement aléatoire des zones mémoire, il faut qu'il est été compilé en PIE (Position Independent Executables) ce qui est loin d'être le cas de la majorité des exécutables sur la plupart des distribution (mais heureusement c'est le cas pour les plus sensibles).

    Le PC depuis lequel j'écris ce post fonctionne sur une Mint 17 à laquelle j'ai ajouté GRSecurity (dans un but purement expérimental). Lors de la compilation du noyau (parce que oui pour profiter de GRSecurity il faut commencer par recompiler son noyau) j'ai pu activer presque toutes les options de sécurité. Les exceptions étant :
    * GRKERNSEC_IO qui empêche X de fonctionner.
    * SYSFS_RESTRICT qui fait planter le driver graphique Intel.

    Il faut aussi savoir que utiliser GRSecurity signifie dire adieu à polkit (le truc graphique qui vous demande votre mot de passe lorsque vous lancez synaptic par exemple). Maintenant pour administrer ma machine je dois d'abord ouvrir un shell root puis passer en mode admin. Ça me fait trois mot de passe à retenir (utilisateur, root et admin).

    En dehors de ça GRSecurity ne pose pas de problème pour une utilisation quotidienne (web, mail, chat, compilation, musique, pornvidéo, youtube, flash…). Plus tard je prévois de le tester sur une autre machine sur laquelle j'utilise les drivers proprio NVidia et Steam. Il faudra surement faire quelques ajustements pour que ça marche.

    Et pour finir, il ne faut pas oublier que sous X, n'importe quel processus, peu importe les droits dont il dispose, peut voir absolument tout ce que vous tapez au clavier, et donc récupérer vos mots de passe sans soucis. Il n'existe, à ma connaissance, aucune protection contre ça. Il semble que la sécurité de Linux ai encore beaucoup ce chemin à faire.

    • [^] # Re: grsecurity

      Posté par . Évalué à 2.

      PAX demande pas mal de configuration car certaines applications (firefox, python, mono…) sont incompatibles avec certains mécanismes de protections (par exemple Python a besoin que sa pile soit exécutable).

      Serait-ce lié au fait que tous les outils dont tu parles interprètent (et donc compilent en JIT) un fichier? Firefox interprète JS, python les .py, mono les je-ne-sais-quoi (.exe?)… avec java, ça donne quoi, même combat?

      Il n'existe, à ma connaissance, aucune protection contre ça.

      Lancer un serveur X par application :D Je déconne, mais en fait, il y à wayland qui, en théorie, est protégé contre ce problème (c'est un de leurs arguments massue en fait, mais je parle de théorie parce que je n'ai pas vérifié…).

      En tout cas, merci pour ce message informatif.

    • [^] # Re: grsecurity

      Posté par (page perso) . Évalué à 2.

      Si un attaquant arrive à compromettre le noyau lui même alors c'est game over, il aura absolument tout pouvoir sur la machine.

      C'est un peu le principe de l'exploit via le noyau hein.
      À part avoir un système de lecture-seule non désactivable, un noyau est forcément vulnérable en cas de… vulnérabilité.
      Et là forcément tout devient possible, vu que le noyau est tout puissant.

Suivre le flux des commentaires

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