Script de test des mesures de protection pour Linux

Posté par  . Modéré par patrick_g.
Étiquettes :
28
2
mar.
2010
Sécurité
Si vous vous intéressez un tant soit peu aux mécanismes de sécurisation d'un système GNU/Linux, il ne vous aura pas échappé qu'un nombre croissant de barrières contre les malveillances est maintenant proposé pour empêcher l'exécution de code dangereux.

De la méthode de protection NX (pour No eXecute), à l'ASLR (Address Space Layout Randomization) remplissant aléatoirement des zones mémoire ou variables liées aux processus, en passant par les "Stack canaries" destinés à empêcher les dépassement de tampon, nombre de protections standard existent.

Mais comment savoir si ces protections additionnelles, activées la plupart du temps sans l'aval de l'utilisateur final, sont réellement effectives ou si leur mise en œuvre est plutôt aléatoire au sein du système ?

C'est dans cet esprit que Tobias Klein (de TRAPKIT.de) a écrit le script checksec.sh, avoir en quelques commandes l'état de protection/d'activation sur processus et exécutables (ou processus en cours), librairies liées ou exécutables d'un dossier.

Les commandes disponibles
checksec.sh --proc
checksec.sh --proc-all
checksec.sh --proc-libs
checksec.sh --file
checksec.sh --dir

Le script checksec.sh est intéressant pour apprécier le niveau de solidité d'une distribution par défaut, peut-être raison pour laquelle la distribution Tin Hat l'a adopté récemment et intégré au système .

Aller plus loin

  • # Protection de Linux ? ou GNU/Linux ?

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

    En lisant le titre de la dépêche, j'ai d'abord cru qu'il s'agissait d'un outil de protection destiné au noyau.

  • # Intéressant

    Posté par  . Évalué à 4.

    J'ai commencé à jouer un peu avec, et c'est effectivement pratique.
    Notamment, mes binaires n'ont pas de canary, alors que je pensais le contraire.. (sshd est le seul a avoir le canary :) )

    Ceci dit, ce genre de soft demanderait une doc expliquant les termes;
    RELRO, je ne vois pas trop ce dont il s'agit, PÏE, etc, les avantages et inconvénients de les mettre en oeuvre ça serait bien.
    J'ai par exemple des 'partial RELRO' (???)

    Sur une machine non x86, aucun executable n'est indiqué comme ELF :-) ce qui semble être une erreur..

    • [^] # Re: Intéressant

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

      Bon quelques résultats sur Debian Lenny. NSCD est complet au niveau mesure de sécurité. Les autres qui sont un peu plus que "NX enabled" :

      nscd Full RELRO Canary found NX enabled PIE enabled
      cupsd No RELRO Canary found NX enabled No PIE
      smbd Partial RELRO No canary found NX enabled No PIE
      nmbd Partial RELRO No canary found NX enabled No PIE
      dbus-daemon Partial RELRO No canary found NX enabled PIE enabled
      sshd No RELRO Canary found NX enabled PIE enabled

      Ce serait bien de tenir un annuaire des distributions et de logiciels

      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

      • [^] # Re: Intéressant

        Posté par  . Évalué à 10.

        Entre les canary et les PIE, ne risque-t-on pas d'y laisser des plumes?


        ça tombe bien, il y a du soleil ~~~~~~>[¨]

    • [^] # Re: Intéressant

      Posté par  . Évalué à 5.

      Sauf erreur de ma part:

      - RELRO signifie relocation table read-only.
      Activé lors de la compilation, la différence entre Partial RELRO et Full RELRO est au niveau de la GOT (global offset table). Si compilé avec Full RELRO, la GOT est en lecture seule alors qu'en partial RELRO, la GOT est en lecture / écriture.

      -PIE pour Position Independent Executables ,activé lors de la compilation, ralentit fortement le système (de 10 à 15%) sur architecture x86

Suivre le flux des commentaires

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