Journal Signer les modules

Posté par  .
Étiquettes :
0
6
sept.
2004
En ces temps de "sécurit" aigu, il convient de bien contrôler ce qu'on nous propose (TCPA, DRM, etc). J'avoue être d'une grande méfiance dans ce domaine.

Il y a une petite nouveauté dans Linux qui commence à être exploité.
Il est possible de signer les modules du noyau et interdire de charger les modules qui n'ont pas une signature valide.

La signature est une signature gpg "classique" stockée dans le modules en utilisant les capacités ELF (ce n'est pas un fichier .sig à part).

Le contrôle de la signature est fait "classiquement" par le noyau avec la clée public.

Allons dans le détail :
* dans /usr/src/linux/crypto/signature/key.h il y a la (ou les) clée public gpg (pour contrôler la signature des modules).
* /usr/src/linux/scripts/modsign/modsign.sh signe les modules en utilisant une clée privée gpg.
* La clée public est dans le noyau. Donc pour changer/ajouter une clée public, il faut recompiler le noyau (cette exigence est assez évidente). Une indirection supplémentaire serait un plus (Par exemple : le noyau aurait une clée et un modules signé par la clée privée du noyau contiendrait d'autres clées publics).

C'est assez simple côté utilisateur final mais néanmoins assez chiant à mettre en oeuvre actuellement.

Avantages :
- Il est difficile pour un cracker de charger un modules "méchant" s'il n'est pas signé
- "traçabilité" des modules.

Utilisation "concrète" :

Fedora (et sûrement Red Hat dans un proche avenir) utilise ça.
Le noyau Fedora a une clée public Red Hat :
- "pub 512D/D7186B51 2004-08-16 Red Hat, Inc. (Kernel Module GPG key)"
Évidement, personne (sauf Red Hat) à la clée privée qui signe les modules.

Vous voyez déjà le "drame" :
- si le module n'est pas signé par "M. Red Hat" (ou IBM si sa clée public est aussi ajoutée dans le noyau), alors le module ne peut pas être chargé.

Voilà ce que ça donne :
modprobe: FATAL: Error inserting ext2 (/lib/modules/2.6.8-1.521/kernel/fs/ext2/ext2.ko): Operation not permitted
kernel: An attempt to load unsigned module was rejected

En fait il n'y a pas de problème et ce pour plusieurs raisons :
- Pour que le noyau exige des modules signés il faut explicitement le demander (paramètre enforcemodulesig).
- Le noyau n'est pas signé mais uniquement les modules.
- C'est le noyau qui vérifie la signature des modules et pas l'inverse. Donc on est jamais dépendant des modules et surtout d'un module binaire qui exigerai un noyau signé par Red Hat par exemple.
- Il y a les sources :-)

Cette fonctionnalité a été initialement développé par un développeur IBM.
Elle a été reprise par un dev Red Hat.
Les patchs nécessaires sont dans rawhide (paquet kernel) :
http://fr2.rpmfind.net/linux/fedora/core/development/SRPMS/(...)
Ce sont les patches *modsig*

PS : rpm n'est pas le plus ouvert des standards (par exemple tar ou cpio) mais il n'est pas necéssaire d'avoir rpm pour lire un rpm
/usr/lib/rpm/rpm2cpio.sh :
#!/bin/sh

pkg=$1
if [ "$pkg" = "" -o ! -e "$pkg" ]; then
echo "no package supplied" 1>&2
exit 1
fi

leadsize=96
o=`expr $leadsize + 8`
set `od -j $o -N 8 -t u1 $pkg`
il=`expr 256 \* \( 256 \* \( 256 \* $2 + $3 \) + $4 \) + $5`
dl=`expr 256 \* \( 256 \* \( 256 \* $6 + $7 \) + $8 \) + $9`
# echo "sig il: $il dl: $dl"

sigsize=`expr 8 + 16 \* $il + $dl`
o=`expr $o + $sigsize + \( 8 - \( $sigsize \% 8 \) \) \% 8 + 8`
set `od -j $o -N 8 -t u1 $pkg`
il=`expr 256 \* \( 256 \* \( 256 \* $2 + $3 \) + $4 \) + $5`
dl=`expr 256 \* \( 256 \* \( 256 \* $6 + $7 \) + $8 \) + $9`
# echo "hdr il: $il dl: $dl"

hdrsize=`expr 8 + 16 \* $il + $dl`
o=`expr $o + $hdrsize`

dd if=$pkg ibs=$o skip=1 2>/dev/null | gunzip
  • # utile ?

    Posté par  . Évalué à 2.

    J'ai pas du tout suivi l'histoire mais question a deux balles.

    Si tu peux modprober un module, tu as aussi generalement access a la memoire du systeme (/dev/mem /dev/kmem par exemple [1]). Donc sur un kernel vanilla je vois pas trop l'interet puisque de toute facon tu modifier le code qui fait la verification, le bypasser etc. Enfin ca doit pas etre beaucoup plus dur que de detourner un syscall ou de patcher son noyau a chaud.

    J'ai rate quelque chose ou ca ne change pas grand chose pour "l'utilisateur lambda" ?

    [1] : oui ca peut etre interdit notament par grsec :-)
    • [^] # Re: utile ?

      Posté par  . Évalué à 2.

      > Si tu peux modprober un module, tu as aussi generalement access a la memoire du systeme (/dev/mem /dev/kmem par exemple

      Très juste mais pas très intelligent :-)

      Si tu es déjà root (accès en écriture de /dev/mem), pourquoi aller plus loin ?

      Par contre, il y a parfois des trous de sécurités dans modprobe.

      Je me rappèle d'un fameux "ping -I'module à charger'".

      Tu peux aussi dire que ça fait double emploi avec les signatures de paquet rpm.

      C'est valable pour beaucoup d'élément de sécurité, c'est un pièce de plus qui fait chier les crackers (grsec, execsheild, etc).

      Mon intention avec ce journal, n'est pas de dire que c'est génial. Mais simplement d'indiquer que ce n'est pas "méchant" (type DRM) contrairement à ce que les premières apparences peuvent laisser croire.
      • [^] # Re: utile ?

        Posté par  . Évalué à 2.

        > Si tu es déjà root (accès en écriture de /dev/mem), pourquoi aller plus loin ?

        Reponse la plus classique : rootkit (LKM)
        Autrement tu peux cacher plein de choses dans le noyau, et y faire ton petit nid.

        > Mon intention avec ce journal, n'est pas de dire que c'est génial. Mais simplement d'indiquer que ce n'est pas "méchant" (type DRM) contrairement à ce que les premières apparences peuvent laisser croire.

        Mon intention etait juste de dire que niveau securite (rootage) si ce n'etait pas couple avec d'autres techniques (quid des possibilites de SELinux sur le verouillage des /dev/*mem d'ailleur ? pour fedora notament) ce n'etait pas l'arme ultime, encore vaut mieux la technique BSD du securelevel > 2 (pas de /dev/*mem pas d'access brute aux disques) et de desactiver les modules.

        Pour le reste ca peut etre utile en effet. C'est actuellement dans fedora ? Que je regarde s'il y a moyen de jouer un peu avec ca.
        • [^] # Re: utile ?

          Posté par  . Évalué à 1.

          > C'est actuellement dans fedora ?

          Oui, dans rawhide (voir le journal :-).
          C'est aussi dans le dernier update de FC2.
          Par défaut, ce n'est pas activé mais les modules sont signés.

          > quid des possibilites de SELinux sur le verouillage des /dev/*mem d'ailleur ?

          SeLinux est vraiment un gros plus à mon sens. Autant je considère la signature des modules comme "presque gadget" autant je vois un gros avenir dans SeLinux.
          Par contre SeLinux c'est un peu "artillerie lourd" et délicat.

          FC2 a SeLinux mais désactivé par défaut et l'activation est presque caché.
          FC3 a aussi SeLinux les problèmes semblent beaucoup beaucoup plus rare que dans FC2 et les règles se sécurité sont satisfesantes.
          Si tu veux jouer avec SeLinux, je te conseille FC3. La test2 (qui est correcte niveau qualité) sera dispo dans 1 semaine :
          http://fedora.redhat.com/participate/schedule/(...)

          NB : ça reste une beta et j'ai bien dit que FC3t2 était intéressant pour "jouer" avec SeLinux.

          > ce n'etait pas l'arme ultime

          Personne n'a dit ça ni même sous-entendu.

Suivre le flux des commentaires

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