Journal Espoir, quand tu nous tiens!

Posté par .
Tags : aucun
0
15
nov.
2004
C'est terrible, depuis le temps que je fréquente linuxfr, je ne devrais plus
espérer grand chose mais bon, on sait jamais...

Dans un message récent, je parlais d'une méthode bourrine pour sécuriser une
machine de bureau (https://linuxfr.org/forums/12/4850.html(...)). Comme je n'ai
rien d'autre à faire, je vais réexpliquer mon idée.

Je réfléchissant à le façon de sécuriser une machine desktop le plus possible sans géner trop les utilisateurs. Biensûr, il y a les trucs évidents comme ne pas
laisser l'utilisateur utiliser le compte administrateur, n'installer aucun serveur et
d'autres trucs. Placer un firewall est déjà plus délicat parce que l'utilisateur
peut vouloir utiliser des logiciels qui nécessitent que certains ports soient
ouverts (ftp ou d'autres). De plus, cet utilisateur n'étant pas technophile, il ne
va pas chercher à mettre à jour sa machine toutes les 15 secondes et il ne va
pas s'amuser à installer 10 programmes par jour non plus. D'ailleurs, si on peut
décourager les installations superflues, c'est pas plus mal, ça évite certaines
saloperies.

La technique OSX est pas mal mais je proposais d'aller plus loin. S'arranger
pour que tous les binaires soient sur une partition séparée sur laquelle le
noyau aurait perdu définitivement les droits d'écriture. De cette façon, il
deviendrait impossible d'installer un root-kit ou de compromettre les binaires.

Pour installer un paquet sur une debian (ce que je connais):
On récupère les paquets dans un endroit spécial (/var/cache/apt/archives) puis
on installe. Il est tout à fait possible d'imposer un reboot pour passer en mode
« install » (en single user mode ou quelque chose d'approchant). Une fois
l'installation faite, le système perd les droits en écriture sur la partition et finit
de booter.


Voilà mon idée. J'aimerai avoir vos idées sur la chose. Sachant que les réponses
du genre:« y a un reboot, c'est mal » ne m'intéressent pas. Qu'un serveur ait
un uptime de 1000 ans peut-être intéressant mais un machine de bureau...
Or, je n'ai eu aucune réponse plus argumentée.

Je suis d'accord que pour un administrateur qui gère 1000 machines, il faut des
aménagements comme autoriser un minimum de réseau pour qu'il puisse faire
l'installation sans avoir à se déplacer devant les 1000 machines mais
autrement, je ne vois pas de problèmes majeurs. Si vous en voyez, je suis
preneur.

Frédéric
  • # Cas d'utilisation

    Posté par . Évalué à 2.

    Dans quel cas est il necessaire de se proteger contre les root-kit ?
    Un poste personnel connecté à internet est il vulnérable ?

    Dans ce cas pourquoi l'idée de forcer ou de proposer une mise à jour périodique n'est elle pas recevable ?

    (Tu voulais des réponses c'est ça ?)
    • [^] # Re: Cas d'utilisation

      Posté par . Évalué à 2.

      Effectivement, je voulais des réponses.

      Le terme rook-kit était mal choisi.
      À priori, ce genre de technique empèche un spyware de s'installer sans l'accord
      explicite de l'utilisateur. Il faut que le spyware ailles se copier dans la zone
      d'installation, attendes le reboot et à ce moment, il faut que l'utilisateur accepte
      d'installer un programme qu'il n'a pas demandé.

      De plus, si le système n'accepte d'exécuter que des binaires venant de la
      partition « binaires », cela empêche aussi le spyware de se placer dans le
      /home et de modifier le .xsession (ou autre technique de ce genre).

      Cela n'empêche pas les chevaux de troie ni les virus de macro et cela ne garantit
      pas l'intégrité des données de /home mais c'est une protection beaucoup plus
      importante.


      Je ne dis pas que ma technique est l'arme ultime mais que c'est une façon pas
      trop intrusive d'augmenter de façon importante la sécurité. De ce point de vue,
      demander à l'utilisateur de faire des mises à jours toutes les semaines est plus
      contraignant, même s'il vaut mieux le faire. De plus, certaines personnes n'ont
      pas encore l'ADSL et sur un modem RTC, les mises à jours...
      • [^] # Re: Cas d'utilisation

        Posté par . Évalué à 2.

        tu parles d'une faille recente de osX non?
        si tu changes tout simplement les droits sur cette "zone d'installation" pour que seul root puisse y ecrire c'est pas plus simple?
        • [^] # Re: Cas d'utilisation

          Posté par . Évalué à 2.

          > tu parles d'une faille recente de osX non?

          Heuuu...
          Non.
          La seule raison pour laquelle j'ai mentionné OSX est que c'est le premier
          unix orienté desktop dont j'ai entendu parlé qui s'arrange pour « virer »
          root. Et je trouve que c'est bien.
  • # de l'idée a la realisation

    Posté par . Évalué à 1.

    il y as un pas.
    Sachant que c'est le kernel qui autorise ou non l'ecriture sur le disk on ne peut pas dire que lui supprimer le droit d'ecriture du cette partition par un chmod par exemple servent a grand chose.Il faut dont deux kernel distinct(un complet et un modifié sans les operations d'ecriture disk).
    Sachant qu'en amputant le kernel des routines d'ecritures il faudrait avoir deux type de peripherique distinct pour que ca marche (un disque ide avec le code complet ecriture/lecture(pour les fichiers des user) et un disk scsi sans la possibilité d'ecriture pour le stockage des binaires et de l'os) ca devrait pouvoir marché....
    le plus simple pour essayer ton idée c'est une clef usb avec un verrouillage d'ecriture positionnée et tu auras l'occasion de voir l'ampleur de la tache de la configuration a prevoir pour que cela marche dans les moindres details.
    • [^] # Re: de l'idée a la realisation

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

      Ce qui peut être imginable serait de jouer également sur fstab:
      ro pour les partitions binaires
      noexec sur les partitions home
      pour un démarrage normal
      rw pour la partion binaire lors d'une install, aprés reboot
      Avec effectivement deux noyau, l'un permettant l'écriture et l'autre non, pour éviter tout changement intempestif (ce qui obligerait j'imagine à avoir /home et / sur deux fs distinct (ext3 pour l'un, reiserfs pour l'autre, par exemple))
      • [^] # Re: de l'idée a la realisation

        Posté par . Évalué à 3.

        > ro pour les partitions binaires

        Si tu choppes le root ou faille noyau ca sert a rien. On retourne a la case depart puisqu'il fallait deja le root pour modifier les binaires installés

        > noexec sur les partitions home

        noexec est une vaste blague sur les 2.4, sur les 2.6 ca a un peu changé et on peut enfin empecher l'execution de fichiers binaires (il reste toujours les interpreteurs)

        > rw pour la partion binaire lors d'une install, aprés reboot

        Donc il suffit d'attaquer a ce moment la. Donc il faut rendre impossible cela, donc ca devient ultra super lourdingue.

        > Avec effectivement deux noyau

        Ca sert a quoi concretement ? Si tu peux prendre la main sur l'un tu peux prendre la main sur l'autre...
        • [^] # Re: de l'idée a la realisation

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

          noexec est une vaste blague sur les 2.4, sur les 2.6 ca a un peu changé et on peut enfin empecher l'execution de fichiers binaires (il reste toujours les interpreteurs)
          Le coup du /lib/ld.so marche plus sur les 2.6 ?
          • [^] # Re: de l'idée a la realisation

            Posté par . Évalué à 2.

            Pas a ma connaissance. J'ai pas investigué plus que ca non plus mais un thread recent sur incidents@securityfocus n'a pas non plus mis en evidence que c'etait possible sur les 2.6; je pense donc que le problème est corrigé.
      • [^] # Re: de l'idée a la realisation

        Posté par . Évalué à 2.

        Disque montés en ro dans fstab:
        Sans redemarrer:

        mount -o remount,rw /usr

        Resultat: si jamais une faille permet d'executter du code avec des droit root, c'est mort .
        A momn avis, comme dit plus haut: soit ton peripherique gere le ro au niveau materiel, soit le noyau est compiler sans l'ecriture ...
    • [^] # Re: de l'idée a la realisation

      Posté par . Évalué à 2.

      OpenBSD permet ce genre de choses avec le concerpt de « securelevel »
      (http://www.openbsd.org/cgi-bin/man.cgi?query=securelevel&apropo(...))

      En niveau 1, on peut placer un flag immutable sur des fichiers et la seule façon
      de pouvoir à nouveau ecrire sur ces fichiers est de rebooter.

      Je ne sais pas si linux permet ce genre de chose mais j'imagine qu'il existe des
      patch pour faire des choses semblables.
  • # Bof

    Posté par . Évalué à 0.

    > S'arranger pour que tous les binaires soient sur une partition séparée sur laquelle le noyau aurait perdu définitivement les droits d'écriture.

    Le noyau ne peut pas perdre les droits d'ecritures. Si tu as le controle sur le noyau tu peux lui rajouter le code necessaire pour ce que tu veux.

    Tu peux a la limite utiliser la technique des BSDs (ou grsec) pour augmenter la difficultee technique de la chose

    1/ interdire /dev/mem et /dev/kmem (pas de bol X marche plus :-)
    2/ interdire l'access brute aux disques

    > impossible

    En sécu impossible je connais pas désolé.

    > je ne vois pas de problèmes majeurs. Si vous en voyez, je suis
    preneur.

    Moi ce que je vois c'est que tu balances une idée en l'air sans en comprendre les tenant et les aboutissant. Quand on propose une idée en sécu on a pour habitude de faire quelques trucs basiques comme.

    1/ présenter le problème de manière générale
    2/ Présenter notre solution
    3/ Présenter techniquement en quoi notre solution resoud le problème (et les problèmes qu'elle peut apportée)

    Présente au moins *un* cas précis de manière technique ou ta solution apporte quelque chose, hormis de grandes idées et ca aura peut etre un interet.

    Au fait, il se passe quoi si l'archive telechargée est pas la bonne ? Ou puisque tu vas ecrire a un moment cette archive toute personne avec les droits suffisant pourra y ecrire aussi... Enfin y'a d'autres idees comme ca
    • [^] # Re: Bof

      Posté par . Évalué à 1.

      Prends-moi pour un con.

      Je sais bien que la sécurité absolue, ça n'existe pas, je sais bien qu'il y aura
      toujours des trous de sécurité. Je sais bien qu'on ne peut pas être sûr que les
      mesures de sécurité mises en place ne seront pas détournée.

      Ce que je cherche, ce n'est pas la sécurité absolue: la sécurité informatique
      absolue, c'est de ne pas avoir d'ordinateur. Ce que je cherche, c'est comment
      microsoft, apple ou redhat peut s'arranger pour rendre son système plus sûr
      de façon notable sans faire chier le client. Car la sécurité, c'est avant tout
      quelque chose de chiant et de pénible car c'est avant tout quelque chose qui
      contrôle et qui interdit.

      Je pars du constat qu'une machine windows non administrée se retrouve vite
      bourrée de spywares, virii et autres. Si on excepte les virus de macro et les
      chevaux de troye, ce genre de chose existe parce que du code à pu s'exécuter
      sans que cela ait été voulu. Pour se protéger de ce genre de chose, il faut donc
      éviter qu'un bug puisse conduire à l'execution arbitraire de code. Une première
      approche consiste à empêcher cette exécution très tôt (W^X, malloc
      randomisé, etc...). Maix comme tu le dis si bien, il se peut qu'un attaquant
      arrive quand-même à faire exécuter son programme. Or l'une des premières
      choses que l'attaquant va essayer de faire, c'est rendre cet exécution pérène.
      Si un simple reboot permet de virer tous les spywares et tous les virus,
      l'attaquant n'a pas gagné grand chose. Pour péréniser son attaque, il doit
      pouvoir écrire sur le disque des informations. De plus, ces informations doivent
      être exécutée de façon automatique. Ce que je propose a pour but de rendre
      cette seconde étape plus difficile.

      Si toutes les partitions sur lequel un utilisateur peut écrire sont montées en
      noexec, c'est déjà un premier pas. Cependant, comme l'attaquant est fourbe,
      il va trouver une faille de sécurité et arriver à devenir root. Dans ce cas, il
      peut écrire dans /etc/rc2.d pour que son truc se lance au démarrage. Si
      on s'arrange pour que root ne puisse pas écrire dans /bin /sbin /usr /lib...
      et qu'un programme doive faire partir d'un de ces répertoires pour être lancé,
      la tâche de l'attaquant devient plus dur: il doit trouver le moyen pour rendre
      à root les droits d'écriture aux endroits ou il ne les a plus.

      Evidemment, ce n'est pas complètement sûr mais ça complique la tâche de
      l'attaquant.
      • [^] # Re: Bof

        Posté par . Évalué à 2.

        > Si toutes les partitions sur lequel un utilisateur peut écrire sont montées en
        noexec, c'est déjà un premier pas.

        Bha il ecrira son code en Perl :-)

        > devenir root.

        Dans une configuration ordinaire c'est perdu.

        Autrement ce que tu cherches a faire c'est du SELinux, utiliser le module RBAC de grsec ou creer une police MAC pour FreeBSD. Tous permettent d'outre passer l'idée du root tout puissante d'UNIX et de limiter les actions des acteurs dans le système.

        Et bien entendu en cas de faille noyau c'est game over dans tout les cas.

        Le point critique de ton truc est "Comment je fais les mises a jour" ? Si on peut reproduire l'attaque pendant la mise a jour ca n'a que peu d'interet. Il est aussi a reflechir si le cout impliqué n'est pas superieur a avoir un master que l'on replique periodiquement ou quelque chose du genre (on parle de postes clients la non ?).
        • [^] # Re: Bof

          Posté par . Évalué à 2.

          > Bha il ecrira son code en Perl :-)
          :) Ça rejoint ce que je disais pour les virus de macro.
          Si son fichier à les droits en exécution, c'est un exécutable et il est traité
          comme tel. Sinon, il faut faire
          # perl virus
          et là, pour augmenter la sécurité, il faut changer l'utilisateur. Je suis bien
          convaincu que le fishing et autres techniques de social engenering sont
          applicable mais c'est autre chose.


          Oui, ce que je veux, c'est du SELinux ou autre et oui encore, le
          problème se pose quand on fait une mise à jour.

          Si on arrive a mettre en place un système de clef, de sertificat ou autre, on peut
          être à peut près sûr de faire une mise à jour depuis le bon site. Évidemment, si
          le site est compromis, on est eu.
          Au moment où on fait l'installation, la machine est plus vulnérable car on doit
          authoriser certaines opérations dangereuses (écrire sur le disque). L'idée est
          donc de passer temporairement dans un environnement beaucoup plus contraint
          (sans réseau, sans serveur d'impréssion, éventuellement sans serveur
          graphique). Une telle configuration n'est certe pas viable en utilisation courante
          mais juste pour une installation de programmes, cela me paraît convenir.

          Et je vois mal comment une attaque réseau peut être réalisée si
          - le système est sain;
          - les fichiers à installer sont authentifiés;
          - aucune communication avec l'extérieur n'est possible.

          Biensur il reste possible de modifier les fichiers de configuration qui se trouvent
          dans /etc. Mais il y a rarement une option « installer une backdoor »
          configurable dans /etc dans les programmes normaux.
        • [^] # Re: Bof

          Posté par . Évalué à 2.

          Merci cykl,

          je continue à trouver ton premier commentaire un poil agressif mais ton second
          me plait pas mal. Comme tu l'as noté, il y a un certain nombre de choses qui se
          font pour sécuriser une machine Linux (SELinux, grsec, pax...)
          Et la mise à jour d'un système reste une partie délicate.
          Au final, ce que je propose n'est rien d'autre qu'une façon violente de gérer ce
          problème de mise à jour.

          Un utilisateur technophile a plus de chances d'avoir un comportement sain
          vis-à-vis de la sécurité informatique (ne pas rester toujours en root, ne pas
          ouvrir tous les mails bizarre...). Cependant, un certain nombre de distributions
          visent directement un utilisateur moins « chevronné ». Celui-ci doit être éduqué
          mais il me semble plus important d'avoir une politique plus volontaire concernant
          la sécurité pour ces personnes. Il me semble que les outils de sécurité mentionné
          peuvent être déployé sans trop géner l'utilisateur. Or, à ma connaissance, ils
          restent confiné à des niches de spécialites.

          Je trouve cela dommage car si pour le moment, Linux n'est pas une cible
          importante pour les virus et autres spyware, il est en train de le devenir et si
          les éditeurs ne font rien, les machines Linux vulnérables qui se baladent dans
          la nature vont finir par devenir un problème.
          • [^] # Re: Bof

            Posté par . Évalué à 2.

            J'ai pas eu l'occasion de regarder en detail ce qu'ils ont fait mais fedora travail pas mal depuis FC2 sur l'adoption d'SELinux par defaut notament pour securiser les démons.

            Le gros problème de la sécurité c'est qu'elle n'est pas vraiment transposable. Certaines choses peuvent etre deployables partout comme PaX (W^X, execshield etc.). Quand tu commences a taper dans les regles SELinux tu commences deja a specialiser la machine. Et si tu veux vraiment un truc efficasse tu as une solution adaptée a *une* problématique.

            Hors le but des vendeurs est de vendre... Et c'est justement pour ca que fedora est passée d'une police strict (qui correspondrait a je bloque tout ce qui n'est pas autorisée du firewall) a une police targeted qui ne vise que des points particuliers. Bref l'etape actuelle est d'empecher la prise de privilege du a l'exploitation d'un serveur. A ma connaissance, hormis utiliser une politique qui empeche les gens de bosser, il n'y a pas de vraie reponse a la problematique des "PEBKAC" et c'est souvent plus simple d'eduquer les utilisateurs que de chercher des solutions purement techniques. Et activer trop de choses par defaut empeche de bosser, genre les securelevel ne sont applicable que si l'utilisation de la machine a ete prevue pour.

            Un mec a presenté y'a pas longtemps un IDS (FreeBSD) basé sur le principe du filtre bayesien sur le comportement des process. Ca pourrait aussi être un deuxieme angle d'attaque meme si ca a des limitations qui sautent aux yeux.
            • [^] # Re: Bof

              Posté par . Évalué à 2.

              Je suis globalement d'accord avec toi mais en fait non.
              Je m'explique. Il y a des choses que l'on peut déployer partout facilement (W^X
              et autres joyeusetés). Ensuite, une politique de sécurité passe par définir ce que
              les personnes/processus doivent pouvoir faire (tout le reste étant interdit).

              Je trouve que les distributions (dans leur grande majorité) ne semblent pas
              s'impliquer activement dans ce genre de politique volontariste. W^X, execshield
              et autres ne sont pas la norme. De plus, en ce qui concerne la sécurité, il y a
              des gens qui développent des outils (SELinux, grsec...). À d'autres de les utiliser.
              Il ne me semblerait pas abérant que /home soit monté par défaut en /noexec.
              Pour une machine de bureau, soit l'utiliseur est root, soit il n'a pas à installer
              de programmes. Dans le cas contraire, la machine est administrée et libre à
              celui-ci de changer le ligne correspondante dans le fstab. Or, ce n'est pas le cas.
              Apt-get (et j'imagine urpmi) n'authentifient pas par défaut les serveurs et les
              paquets qu'ils installent. À la limite debian a un fonctionnement
              ultra-conservateur ce qui peut expliquer cela mais redhat peut imposer ce
              genre de choses. Et si c'est effectivement intégré aux outils, les gens l'auront
              rien à faire de plus.

              Une vraie politique forte de sécurité est forcément intrusive mais je pense qu'il
              reste des choses à faire qui ne sont pas trop contraignantes pour améliorer
              globale d'une distribution.

              Frédéric
              • [^] # Re: Bof

                Posté par . Évalué à 2.

                > pas s'impliquer activement dans ce genre de politique volontariste.

                Dans les distribs grand publique je n'ai vu que gentoo et fedora faire cet effort

                > Il ne me semblerait pas abérant que /home soit monté par défaut en /noexec.

                Et si quelqu'un veut compiler un programme dans son home ? Ou si c'est un poste de developpeur. Ca rajoute au moins une question a l'installation, et on arrive a un nombre de question < 30 au total. Tu imagines le nombre de question dans les forums a ce sujet ? Je comprend que les mecs puissent hesiter, d'ailleur ce que j'aime bien chez fedora c'est qu'ils osent imposer des choix même si ca casse "tout" pour le moment.

                > mais je pense qu'il reste des choses à faire qui ne sont pas trop contraignantes pour améliorer globale d'une distribution.

                Je pense qu'il y a a peu pres tout a faire :-)

                Le problème est que la sécurité impose a tout les utilisateurs une compréhension minimale de la problématique. Et c'est toujours la que ca coince, l'utilisateur va geuler par ce que "ca marche pas". Les permisions unix sont comprehensibles avec un peu d'effort, les ACLs sous linux/bsd sont une plaies. C'est dingue qu'il n'existe pas d'interface graphique integré a gnome ou rox (quid de KDE ?) ! NFSv4 arrive tout juste avec ses ACLs dans les facs on en arrive a devoir mettre des projets en 660 pour pouvoir bosser et donc n'importe qui peut lire/modifier les projets !

                Et la on parle de truc triviaux qui devraient être la base. Ce sont des choses qui ne perturbent pas le fonctionement. Le problème pour les distribs est qu'elles doivent convenir aussi bien au developpeur maison, qu'a l'entreprise et a celui qui tente d'installer linux chez lui. Et c'est trois scenarios sont totalement contradictoires on reintroduit donc une couche de complexité !

                Allez pour finir dans une distribution que je ne citerais pas, le maintainer du gestionaire de paquet ne voulait pas de miroir car ce n'etait pas secure ! Apparement le principe meme de signature electronique n'est pas assimilé par des gens techniques. De même la sécurité est un concept dont énormement de devels n'ont jamais entendu parlé, la même personne ignorait les possibilités qu'offraient les symlinks par exemple...

Suivre le flux des commentaires

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