Supposons que vous administriez une machine distante. Vous n'avez pas d'accès physique à cette machine. C'est ennuyant puisque vous venez de changer la configuration de votre bootloader.

Comment faire pour rebooter tout en garantissant que ca va marcher ?

Hé bien j'ai la solution qui vous permettra de tester ce boot avant de rebooter : qemu.

Préparer les disques

Il nous faut des disques en lecture seule pour éviter que le boot de la machine virtuelle n'écrive sur un disque en cours d'utilisation. Donc pour chacun de vos disques physique :

$ cp -a /dev/sda /root/sda
$ chmod 440 /root/sda

Ainsi nous avons des disques garantis en lecture seule.

Préparer son terminal

Nous allons enregistrer ce qui se passe sur le terminal, lequel va tourner en ncurses, il est donc important pour la lisibilité des logs de le dimensionner à la même taille que l'écran de boot, c'est-à-dire 80x25.

Modifiez la taille de votre fenêtre de terminal jusqu'à ce que les variables $COLUMNS et $LINES vaillent respectivement 80 et 25.

Préparer son bootloader

Quel que soit votre bootloader configurez le de façon à ce qu'il ne lance pas de mode graphique, sinon vous ne pourrez pas stocker les logs de ce qui se passe.

Choisit son qemu

Installez qemu. Puis en fonction du matériel à émuler choisissez qemu-system-i386 ou qemu-system-x86_64 ou une autre architecture si vous travaillez sur d'autres machines.

Lancer le tout

Préparez un 2e terminal pour tuer qemu , ca sera plus simple que d'attendre qu'il se termine proprement (killall qemu pour les impatients).

$ sync
$ ssh -t localhost "qemu-system-x86_64 -m 512 -curses -hda /root/sda" | tee logs

Pourquoi sync ? au cas où vous auriez fait des modification impactant le boot, on force l'écriture de celles-ci sur le disque.

Pourquoi ssh ? Pour profiter de l'option -t qui crée un terminal virtuel même lorsqu'on travaille dans un pipe.

Pourquoi tee ? Pour stocker les logs de ce qui se passe tout en gardant la main sur le clavier. Tout est tellement rapide qu'il peut y avoir des erreurs invisibles.

Pourquoi -m 512 (512Mo de ram): prenez une valeur inférieure à votre matériel mais malgré tout proche pour éviter les effets de bord.

Pensez à ajouter les disques dont vous pourriez avoir besoin selon le niveau de boot que vous voudriez tester.

Lire les logs

Bon, qemu s'est lancé, le boot a planté, mais vous n'avez pas eu le temps de voit l'erreur.

Commencez par tuer le qemu s'il vous gêne. Puis lisez les logs :

$ less -R logs

Pourquoi -R ? parce que cette option vous permet de ne pas traduire les caractères spéciaux que qemu écrit à travers ncurses et vous permet de voir le contenu des logs tels qu'ils sont apparus à l'écran.

Mode graphique

Si vous ne voulez pas de logs ou que vous ne pouvez pas empêcher le mode graphique de se lancer, vous pouvez faire sans. Dans ce cas, à vous de vous connecter à la machine de façon à ce qu'un serveur X soit accessible (par exemple avec ssh -X).

La commande devient alors :

$ sync
$ qemu-system-x86_64 -m 512 -hda /root/sda

PS : Et ça marche avec les outils de virtualisation comme xen.

Lorsqu'on parle de redondance, de haute disponibilité et de disque, on parle de Raid. J'en ai déjà parlé

Voici un petit aperçu des différents types de RAID, le but est ici de trouver les qualités de chacun. Un tableau final récapitule les avantage et les inconvénients qu'il y a à choisir un type de raid donné.

Jbod

Just a bunch of disk, ce n'est pas un raid, le choix de ceux qui veulent pouvoir ajouter des disques bout à bout sans gain de performance.

Contrairement au raid 0 il a un avantage, la perte d'un disque n'empêche pas la récupération des données sur les disques restants par un outil de récupération tel que photorec. En effet, comme les disques sont simplement mis bouts à bout, la plupart des fichiers tiennent intégralement sur un seul des disques. Il est donc possible d'en récupérer le contenu après un crash.

Le jbod se fait avec du LVM sans striping ou avec le driver linear de md.

Raid 0

Le choix de ceux qui veulent des performances.

Chaque disque est découpé en bande (stripe) et les bandes sont entrelacées pour donner le disque final. Ce qui donne un gain de performance appréciable puisque les disque peuvent être lus simultanément, même pendant la lecture d'un gros fichier. Et ils peuvent être écrits simultanément pendant les écritures.

Le raid 0 peut être matériel, logiciel avec le driver md de linux ou logiciel avec LVM (avec striping)

Raid 1

Le choix de ceux qui ne veulent pas de pertes.

Tous les disques sont des copies intégrales. L'avantage le plus important est que lors de la perte d'un disque tout fonctionne comme si de rien n'était. On peut donc remplacer ce disque (ou pas :-).

Un autre avantage existe lors des lectures non séquentielles (lors de la lecture de 2 fichiers par exemple), dans ce cas il est possible d'utiliser un disque pour chaque lecture et donc d'accélérer ce type de lecture. Par contre la lecture d'un seul gros fichier n'est pas accélérée (sous linux).

Il n'y a en revanche aucun impact sur l'écriture, c'est le disque le plus lent qui détermine la vitesse d'écriture (la vitesse devrait être à peu près identique pour chacun).

Notez qu'on peut faire du raid 1 avec plus de 2 disques.

Le Raid 1 peut être matériel, logiciel avec le driver md ou logicielle avec LVM (support du miroring), enfin il est possible de faire du raid1 réseau avec drbd.

Raid 5

Le choix des économes.

En raid 5 chaque disque est découpé en bande, pour chaque groupe de bandes situées au même endroit des disques, une des bandes est choisie pour contenir des octets de redondance (la différence avec le 4 c'est le choix de la bande). Ainsi ce type de raid peut survivre au crash d'un des disques (la redondance permet de reconstruire la bande manquante), mais pas de plusieurs.

L'avantage du raid 5 est que lorsqu'on a de nombreux disques on économise des disques de redondance en n'en achetant qu'un pour la redondance et les autres pour les données.

Mais le raid 5 est assez limité en performances. La lecture se passe comme pour le raid 1. Par contre l'écriture nécessite la lecture de chacune des bandes d'un groupe pour écrire la bande de données, puis calculer et écrire la bande de redondance. C'est donc très lent, à éviter pour les bases de données actives.

D'autre part, lors du crash d'un disque, toutes bandes des disques doivent être lues pour reconstituer une bande manquante. Ce qui implique des baisses de performances énormes, auxquelles il faut ajouter la baisse de performances due à la reconstruction du disque qu'on va remettre. Comme les disque tournent à fond, il n'est pas rare de voir un autre disque exploser en vol à ce moment là -> fin des données.

Le raid 5 peut être matériel ou logiciel avec le driver md de linux.

Raid 6

Le choix des très gros disques.

Le raid 6 fonctionne de la même façon que le raid 5 mais ajoute un deuxième disque de redondance. Ce ne sont pas simplement les données de redondance qui sont dupliquée, mais le calcul qui est différent, toutefois le concept est identique.

Le raid 6 soufre des mêmes inconvénients que le raid 5, il utilise même un disque de plus donc est un peu plus cher, de plus cela provoque une écriture supplémentaire pour chaque groupe de bandes.

Mais le raid 6 résiste au crash de 2 disques, ce qui est intéressant lorsque les disques sont assez gros et que la reconstruction du raid comment à être assez longue (et donc le risque de perte plus gros).

Le raid 6 peut être matériel ou logiciel avec le driver md de linux.

Raid 10

Le choix des riches.

Le raid 10 consiste à accumuler plusieurs raid 1 avec du raid 0 pour en augmenter la taille et les performances.

Le raid 10 offre les avantages simultanés du raid 1 et du raid 0. La perte d'un disque n'empêche pas le raid de tourner et l'utilisation de plusieurs disques en striping permet d'augmenter les performances de lectures.

Le seul inconvénient, c'est qu'il coûte deux fois le prix du raid 0.

Il peut se faire en matériel ou logiciel, md ou lvm.

Raid 0+1

Le mauvais choix.

Le raid 0+1 consiste à mettre 2 raid 0 en parallèle pour les redonder avec du raid 1. On pourrait croire que c'est la même chose que du raid 10, mais non. Et même si certains veulent vous faire croire que les performances sont meilleures, il n'en est rien.

Mais surtout imaginez un instant la perte d'un disque. Dans ce cas un des raid 0 sous-jacent est perdu. Il faut donc le recréer avec un nouveau disque (ce qui est à peu près instantané puisqu'on le laisse vide), puis reconstruire le raid 1 situé au dessus. Et cette deuxième partie va être longue puisqu'elle doit être faite sur la taille totale du raid 0, contrairement au raid 10 qui ne l'aurait fait que sur la taille totale du disque perdu.

Petit récapitulatif

Maintenant que nous connaissons le processus de boot, si on examinait ce processus d'un point de vue de la sécurité !

Lorsqu'on parle de sécurité, il faut d'abord savoir dans quel cas on se positionne et de quoi on cherche à se prémunir. Ici, je considère que le système lui-même est sécurisé. Je suppose que l'attaquant est devant la machine et cherche un accès root.

On considère que chaque élément est sécurisé pour ce qui est de ses propres fonctionnalités, ce qui veut dire que si le bootloader est protégé par mot de passe, il n'y a pas de faille dans le bootloader lui-même permettant d'outrepasser ce mot de passe. Nous nous attacherons donc à chercher ce qui peut être détourné dans le flux d'exécution en entrée et en sortie de chaque élément.

Je vais commencer par la fin, du plus facile au plus difficile.

rc

Rc est lancé par init et ne prend ses paramètres que de init. Ceux-ci sont fixés en dur dans /etc/inittab. Son démarrage ne peut donc être détourné que d'une façon : par modification du contenu du disque. GoTo partition /

Parmi ces paramètres il y a le paramètre 1 qui lance rc dans le runlevel 1, ce qui dans la plupart des cas se termine par un sulogin. Ouf on est protégé par le mot de passe root.

Mais vérifiez bien, dans certains cas il se termine par un simple shell et donc réussir à passer un tel paramètre permettrait à l'attaquant un accès root à votre machine.

Pour passer 1 en paramètre GoTo init

init

Init est lancé par le noyau après lecture de la racine. Il lit sa configuration dans /etc/inittab. Il peut donc être détourné par modification du disque : GoTo partition /

Parmi les paramètres qu'on peut lui passer il y a 1 et S, 1 renvoie au problème ci-dessus et S lance lui-même sulogin, donc même vérification. Ces paramètres viennent du noyau : GoTo noyau

Init est un binaire choisi par le noyau, or il est possible de dire au noyau de changer d'init à travers le bon paramètre. Par exemple, je peux ajouter init=/bin/sh aux paramètres du noyau pour qu'init ne soit jamais lancé qu'un shell apparaisse à sa place. Ça y est je suis root ! C'est d'ailleurs la technique pour changer de mot de passe root lorsque vous l'avez perdu.

Pour changer d'init GoTo noyau.

Init peut aussi être lancé par initrd, il souffre dans ce cas exactement des mêmes problèmes que lorsqu'il est lancé par le noyau : GoTo initrd.

Note upstart, initrdng... :
Il se peut (et ca va être de plus en plus courant) qu'init ou rc soit remplacé par autre chose, type upstart. Dans ce cas seul les noms des paramètres et le format des fichiers change. Mais les impacts sont exactement les mêmes.

Initrd

Initrd prend ses paramètres de la ligne de commande du noyau, mais généralement (il y a plein d'initrd différents) ils sont passés tels quels à init.

D'autre part initrd peut être chargé par 2 moyens, j'ai décrit le bootloader comme un moyen mais le noyau peut aussi charger lui-même l'initrd si on lui demande (avec le paramètre initrd=). On peut donc détourner son chargement par plusieurs moyens : GoTo noyau, GoTo bootloader.

Il est aussi possible de modifier directement l'initrd, par exemple lors d'une réinstallation distante. Celui-ci contenant tout ce qu'on veut, modifier son contenu permet de lancer n'importe que processus ... GoTo partition /boot

Noyau

Le noyau en lui-même ne vous rend pas root mais rien ne vous empêche d'y faire une modification pour qu'il vous fasse root une fois le système chargé.

Le noyau est chargé depuis la partition /boot donc une modification de cette partition et c'est gagné : GoTo partition /boot

Le noyau prend ses paramètres du bootloader, parmi ceux-ci de nombreux paramètres permettent de détourner le système : root= init= initrd= et surement bien d'autres. GoTo bootloader

Partition /

Jusque là, nous n'avons évoqué que les risques mais pas encore de faille. C'est parce qu'aucune interférence de l'utilisateur n'a été possible, tout est automatisé. Mais ça va changer.

Lors du montage de la racine, il y a une interférence possible : le disque contenant / peut avoir été modifié, voire remplacé, pour modifier /etc/inittab, /sbin/init, /etc/init.d/rc ou toute autre chose.

Pour éviter ce problème, il y a deux possibilités :

• mettre un cadenas sur la machine pour garantir l'intégrité physique du disque
• chiffrer le disque

Dans le premier cas, le problème est remonté aux autres couches pour garantir l'intégrité logique et éviter qu'on réussisse à booter sur un autre OS pour modifier le disque. GoTo bootloader.

Dans le deuxième cas, le chiffrement (par exemple avec luks ou truecrypt) doit être assuré par une clé.

• si cette clé est sur la machine et son mot de passe aussi : elle est dans un élément de boot (initrd, partition de boot ...) on reporte le problème GoTo partition /boot
• si cette clé ou son mot de passe n'est pas sur la machine (carte à puce, mot de passe, clé usb ...) alors il y a besoin d'un personne présente à chaque boot ...
• le chiffrement peut aussi être assuré par une puce (TPM) qui ne quitte pas la machine, auquel cas, on garanti que le disque ne quittera pas la machine pour être lu ou modifié (mais pas de garantie contre le formatage), par contre il peut être lu sur place par un autre OS.

Dans tous les cas, seul le démarrage post-noyau est préservé, pour le reste GoTo bootloader.

bootloader

Le bootloader est la source de tous les maux. C'est en effet par lui que l'utilisateur a tout loisir de modifier des paramètres de démarrage.

Le bootloader passe ses paramètres au noyau qui les passe à l'initrd qui les passe à init. Ces paramètres viennent de la configuration du bootloader mais pour un certain nombre de bootloader ils peuvent être directement demandés à l'utilisateur. Dans ce cas il y a moyen d'interdire cette modification à travers un mot de passe. Par exemple grub.

Le bootloader charge sa configuration puis choisit et charge le noyau et l'initrd, tout ceci depuis la partition de boot. Dans tous les cas il doit lire une version non chiffrée, ce qui interdit le chiffrement de cette partition.

Pire, le bootloader est incapable de savoir que le disque n'a pas changé. Donc un simple ajout de disque permet de le faire booter sur un noyau/initrd différent.

Vous ne pouvez presque rien y faire: GoTo partition /boot.

Bon en supposant qu'il n'y a pas de problème, le bootloader est chargé par le bios, il peut donc être détourné : GoTo Bios.

Partition /boot

J'inclue dans la définition de la partition de boot tout ce qui contient la configuration du bootloader, le bootloader lui-même, le noyau et l'initrd, même si ils peuvent être physiquement à des endroits différents. Protéger la partition de boot est très complexe, car tout doit être accessible en clair depuis des outils ayant des fonctionnalités très restreintes.

Les possibilités sont :

• sceau physique sur la machine
• TPM

Mettre un gros cadenas sur la machine permet d'éviter une lecture ou une modification de /boot. Mais il on ne se prémunit pas d'une personne un peu patiente avec un accès complet à la machine.

La dernière solution, complexe à mettre en place et sans garantie absolue est d'utiliser une puce TPM qui va vérifier (mesurer) le bootloader à chaque étape de son chargement, puis vérifier chaque élément que le bootloader charge avant de lancer le noyau.

Bios

Le bios s'exécute tout seul depuis lui-même, il se charge puis lis ses paramètres. Parmi ces paramètres il y a la séquence de boot, qui peut elle-même être modifiée par l'utilisateur.

Il est donc possible, voire facile de dire au bios de booter sur une clé USB et de prendre le contrôle du disque et donc de la machine. Pour éviter ce cas de figure il est possible de mettre un mot de passe au bios. Ainsi on est sûr de booter sur le bon disque, mais seulement s'il y a un cadenas sur la machine puisque le bios ne vérifie pas que le disque n'a pas été remplacé.

GoTo Matériel.

Matériel

Il est possible de changer le bios lui-même. Et ce de plusieurs façons. Si c'est un flash, il est possible de le remplacer logiciellement, si c'est une rom il est possible de la remplacer matériellement.

Et enfin le plus simple pour remplacer le bios est de remplacer la carte mère. Hop ni vu ni connu ...

Pour se protéger de cela ? Le cadenas ... ou la puce TPM, dont la mise en place est toujours très complexe et non garantie.

Conclusion

Résumons-nous car cet article commence à être un peu long. Différencions les cas dont on veut se protéger.

Accès réseau

Si l'attaquant n'a accès à la machine que par le réseau, on est tranquille pour ce qui est de la séquence de boot : No problemo.

Accès KVM

Si l'attaquant n'a accès à la machine que par KVM (pas de possibilité de toucher aux périphériques). Mettre un mot de passe sur le bootloader, le bios et vérifier que le mode rescue demande le mot de passe root devrait suffire. En effet les seul moyen d'attaque sont les paramètres de lancement du système.

N'oubliez pas que le simple accès KVM permet des choses comme le reboot via les magic keys

Accès cadenassé

Si on suppose que l'attaquant peut apporter un CD ou une clé usb sur le système, paramétrer le bios pour booter sur un disque et y mettre un mot de passe est un moyen simple à mettre en place pour éviter le boot sur un autre système.

Mais attention, il ne faut pas que l'utilisateur puisse ouvrir la machine, il pourrait réinitialiser le bios.

Accès au disque sans droit de boot

A partir du moment où l'attaquant a accès au disque c'est presque foutu. Si l'attaquant n'est pas une personne autorisée à booter la machine, il est possible de chiffrer le disque avec une clé qui ne se trouve pas sur le disque. Il faudra alors la rentrer à chaque démarrage. L'attaquant ne disposant pas de cette clé, il me pourra ni lire ni modifier les données où le système. Mais c'est déjà une solution assez contraignante.

D'autant plus que pour être complète cette solution doit garantir le noyau et l'éventuel initrd sur lequel on boote et donc vérifier soi même à chaque boot qu'on utilise une partition de boot non modifiée.

On en arrive au dernier cas ...

Accès complet

Lorsque l'attaquant a un accès complet à la machine, il n'existe qu'un moyen de se protéger (et encore) : la puce TPM.

Elle permet de :

• protéger le bios d'un changement
• protéger le bootloader d'un changement
• protéger le noyau d'un changement
• protéger le contenu du disque d'un changement

Mais tout cela est compliqué et nécessiterait un autre article que je ne suis pas encore prêt à faire, je n'ai même pas de puce TPM chez moi.

PS : Notez une dernière chose que je n'ai pas abordé, le chiffrement des données. Le chiffrement du disque contenant les données (/home et /srv selon vos besoins) devient obligatoire dès qu'on prévoit qu'il y aura un accès physique. Il doit de préférence se faire avec un moyen propre à l'utilisateur (mot de passe / clé / carte à puce ...) pour éviter les attaques à travers le boot de l'OS.

PPS : Considérez qu'a partir du moment où quelqu'un a un accès physique à votre machine c'est mort.

PPPS : Sauf si votre machine est une carte à puce.

PPPPS : Et encore ...

Bon courage !

Maintenant que vous avez étudié git, voyons à quoi il peut servir.

Configuration

Git peut, entre autre, fonctionner en local, comme RCS. Git est plus intéressant que d'autres outils comme svn pour plusieurs raison :

• Il stocke tout en local à la racine du répertoire de travail
• Il n'éparpille pas de fichiers un peu partout
• Il prend 2 à 3 fois moins de place que svn pour des petits fichiers comme les fichiers de configuration
• Il est un ordre de grandeur plus rapide que svn (ce qui importe peu pour /etc)

Notez que mercurial répond aussi à ces besoins.

Git est donc parfaitement adapté à votre configuration qui se trouve dans /etc :

# En root
$ cd /etc
$ git init

J'ai commencé par faire un "git add *" mais en pratique ce n'est pas une très bonne idée car on récupère tout et n'importe quoi et à moins de ne pas avoir de backup, ce n'est pas très utile. En effet cela entre en conflit avec les gestionnaires de paquet et gestionnaire s de configuration et c'est assez gênant lors des migrations. Une bonne utilisation est plutôt de faire un "git add" uniquement pour les logiciels dont on modifie la configuration. Ainsi, vous avez dans votre dépôt toutes vos modifications et uniquement vos modifications. Cela nécessite de s'imposer de faire les "git add" mais c'est plus simple.

D'autre part, rien ne vous empêche d'avoir un cron de commit automatique pour rattraper les cas où vous oubliez de le faire.

# Autocommit une fois par semaine, s'il n'y a rien à commiter, il ne fera rien
0 0 * * 1 cd /etc && git commit -a -m "Autocommit by cron"

Le jour où vous avez un problème de configuration :

# On cherche ce qui a changé depuis le dernier commit (fonctionnel ?)
$ git diff
# On cherche quand ça a changé avant
$ git log
# On cherche ce qui a changé avant
$ git diff ee9eac2a4deb43e7c73b50444fcb7269f172fb69

Ma configuration

Mieux, j'utilise maintenant git pour mon home :

$ cd 
$ git init

Pour le coup, on ne met vraiment que ce qu'on modifie, au coup par coup. Pour savoir quoi y mettre, commencez par lister tout ce qui commence par un point :

$ ls -ad .*

A vous de savoir ce que vous voulez y mettre sachant que ça sera transféré sur toutes vos machines. Exemples :

• .bashrc et les .bash_*
• .irssi
• .vimrc
• .ssh
• .gnupg

Et du coup, il devient facile de se "téléporter". Dès que j'obtiens un compte sur une nouvelle machine, j'y emporte toute ma configuration. C'est assez simple (avec toutes les options) :

# Avec un git récent et une connexion bidirectionnelle
$ ssh peck@machine2.net
$ git clone ssh://peck@machine1.net/~peck/.git .

# Si la communication retour ne fonctionne pas directement
$ ssh -R 1022:localhost:22 peck@machine2.net
$ git clone ssh://peck@machine1.net:1022/~peck/.git .

# Si git se plaint de ne pouvoir créer le répertoire de destination
$ ssh peck@machine2.net
$ git clone ssh://peck@machine1.net/~peck/.git temporary
$ mv temporary/* .
$ rmdir temporary

De par le côté décentralisé de git, vous pouvez faire les modification où bon vous semble et les propager au fur et à mesure de votre usage. Voyons cela !

Ne pas oublier de de commiter

Pour les gérer les oublis, Vous avez le choix entre un autocommit régulier (voir plus haut) et un warning automatique à chaque connexion

# dans mon .bashrc
$ git status | grep modified

Vérifier les mises à jour à chaque connexion

A chaque nouvelle connexion faites un git pull, cela vous mettra à jour les données en provenance de la machine parente. Vous avez ainsi une synchronisation quasi automatique de vos répertoires personnels entre vos comptes.

# je le mets dans mon .bashrc mais c'est assez lourd si vous n'avez pas de clé ssh
$ git pull

Pousser une mise à jour vers le parent

Lorsque vous faites une modification sur un machine qui n'est pas la source (celle pour laquelle vous n'avez pas fait de git clone), il est appréciable de faire un git push pour propager les choses dans l'autre sens. Un inconvénient toutefois, c'est un lourd difficile à faire. Le plus simple est de récupérer les données depuis la source, mais ce n'est pas toujours facile à faire, cela peut nécessiter plusieurs tunnels.

# Sur la machine du changement 
$ git commit -a
# Sur la source
$ git pull ssh://peck@machine1.net/home/peck/.git

Suite à un article sur les processus, j'ai trouvé une excellente série d'article vous permettant de découvrir le fonctionnement interne du noyau sur les processus et la mémoire :

• memory-translation-and-segmentation
• getting-physical-with-memory
• anatomy-of-a-program-in-memory
• how-the-kernel-manages-your-memory
• page-cache-the-affair-between-memory-and-files

Maintenant, essayons de résumer la gestion des processus d'un point de vue utilisateur et développeur.

Naissance, vie et mort d'un processus

Un processus est créé lorsque l'appel système fork est appelé et seulement dans ce cas. Les autres méthodes possibles se basent toutes sur fork (et clone, mais il ne faut pas le dire). Fork ne fait qu'une chose (et il le fait bien), il duplique un processus existant, entièrement, à l'identique, y compris ses droits.

Ensuite, durant sa vie un processus peut être modifié de nombreuses façons :

• Changement d'utilisateur
• Changement de code
• Changement de père
• Changement de priorité
• etc.

Enfin un processus meurt dans 2 cas :

• Il se termine tout seul comme un grand (appel système exit)
• Il reçoit un signal qui lui est fatal

Informations sur un processus

Informations générales

Pour récupérer des informations sur un processus vous disposez de plusieurs commandes. Ces commandes ou toutes pour source /proc/<pid> qui est un répertoire virtuel peuplé directement par le noyau.

Les commandes les plus courantes sont :

• ps : liste des processus et de leurs caractéristiques
• htop : liste dynamique des processus et de ce qu'ils consomment
• pgrep : récupération d'une liste de processus par expression régulière
• pidof : récupération du pid d'un processus recherché
• fuser : informations sur les file descriptor d'un processus
• lsof : idem
• pmap : afficher le mapping mémoire d'un processus

Données sur l'activité

Un processus a une activité somme toute limitée, c'est pourquoi il est parfaitement faisable de tout tracer. Le plus évident est de tracer les appels système, mais cela ne révèle que ses interactions avec le reste du monde. Il est aussi possible de tracer les appels de fonctions voire chacune des instructions.

• strace : liste les appels système du processus
• ltrace : liste les appels de fonction de bibliothèques dynamiques (.so) du processus
• pstack : affiche la pile d'appel du processus
• gdb : avec gdb on peut tout savoir et même modifier l'action d'un processus. gdb utilise l'appel système ptrace pour cela.

Agir sur un processus

Les actions sur un processus peuvent être effectuées par plusieurs entités :

• Le processus lui -même
• Le processus père du processus
• Un autre processus ayant les droits pour effectuer une action (c'est-à-dire même propriétaire ou root ... en l'absence de patch sur le noyau)

Les actions qu'on peut effectuer sur un processus sont toutes liées à un appel système. En général il existe une commande shell fournissant une fonctionnalité équivalente.

Envoi d'un signal

Les signaux permettent de communiquer de façon basique avec un processus. Il peuvent être envoyé par un autre processus ou par le noyau. man 1 kill vous indique la liste des signaux et l'action par défaut associée pour les processus qui ne les surchargent pas.

Pour envoyer un signal à un processus il existe plusieurs commandes (qui utilisent toutes l'appel système kill) :

• kill : envoyer un signal à un processus connaissant son pid
• killall : envoie un signal à tous les processus portant un certain nom
• pkill : envoie un signal aux processus matchant une expression régulière
• ctrl-z : envoie le signal STOP au processus en avant plan du shell en cours
• fg, bg : envoie le signal CONT à un processus stoppé du shell en cours

Répartir les tâches

Les processus peuvent être plus ou moins consommateurs de ressource processeur. La partie du noyau nommée ordonnanceur (scheduler) s'occupe d'allouer ces ressources aux différents processus.

Pour influencer l'activité de l'ordonnanceur, il existe plusieurs méthodes. Tout d'abord chaque processus dispose d'une priorité, le niveau de nice. Pour altérer son propre niveau, il y a l'appel système nice qui a donné la commande nice. Pour altérer celui d'un autre processus il y a l'appel système setpriority qui a donné la commande renice.

L'ordonnanceur a la charge de répartir l'activité de plusieurs processus, de plus en plus souvent entre plusieurs processeurs. Il est possible d'influencer la répartition des processus entre processeurs avec la commande taskset (utilisant l'appel système sched_setaffinity). Cette commande permet de limiter un processus à un ou plusieurs processeurs donnés.

Il existe aussi avec CFS, un moyen de contrôler finement le temps alloué à chaque processus à travers /sys/kernel/uids ou à travers les cgroups (voir Documentation/scheduler/sched-design-CFS.txt).

De plus il existe dans le noyau un deuxième ordonnanceur qui, cette fois, organise les tâches d'accès au disque. Si c'est le CFQ qui a été choisi (car il est modifiable), il est possible de l'influencer. Le grand intérêt de ceci est de limiter les processus qui pourraient phagocyter les autres en faisant énormément d'accès disque (pensez aux backups). L'appel système ioprio_set est implémenté dans la commande ionice pour gérer cette fonctionnalité. Lisez Documentation/block/ioprio.txt pour plus de détails.

Gestion des droits

Il n'est pas possible de changer les droits d'un processus de l'extérieur. Seul lui-même en est capable. Mais le mécanisme standard d'héritage lors du fork et de changement de droits lors de l'exec permet de faire tout ce qu'on veut.

Il n'existe qu'un seul cas où les droits peuvent être augmentés (en supposant l'absence de patch de sécurité spécifique) : lancer la commande exec sur un fichier disposant du bit suid (et éventuellement de capabilities).

Ensuite pour réduire ses droits, le processus peut utiliser :

• L'appel système chroot qui a donné la commande chroot
• L'appel système setXXuid qui est utilisé dans pam (commande login par exemple)
• Les capabilities à travers l'appel système setcap qui permet de limiter la liste des appels systèmes disponibles pour un processus (ceci est une option du noyau)

Devenir indépendant

Un processus reçoit des signaux mortels lorsque son tty est coupé. C'est pourquoi un processus peut vouloir obtenir son indépendance.

Il appelle alors l'appel système setsid qui le détache de son terminal. De plus il crée un nouveau groupe de processus pour lui et ses fils, ce qui en pratique le détache de son père (lequel ne pourra donc plus le tuer lorsqu'il mourra).

La commande setsid fait la même chose en ligne de commande.

Limitations

Il est possible d'imposer des limitations à un processus ainsi qu'à ses fils, il existe un appel système pour cela nommée setrlimit. Bash propose une implémentation en ligne de commande pour cet appel nommée ulimit.

Les limitations incluent des limitations en nombre de fichiers ouverts, en consommation CPU, en occupation mémoire ... vous trouverez les détails dans le manuel de bash à la commande ulimit.

IPC et mémoire partagée

Une ancienne méthode chamanique utilisée pour communiquer entre processus est constituée des IPC (inter process communication). Les ipc permettent à des processus de :

• s'envoyer des messages (appels système msgXXX)
• poser des sémaphores, une technique de lock pour l'accès à des données (appels systèmes semXXX)
• partager de la mémoire (appels système shmXXX)

Ces 3 catégories de méthodes génèrent des données qui sont indépendantes des processus de par le fait qu'elle sont destinées à d'autres processus. C'est pourquoi lorsqu'un processus utilisant des ipc plante, il laisse des traces dans le système. Ces traces consomment de la mémoire inutilement et parfois bloquent d'autres processus.

C'est pourquoi les commandes ipcs et ipcrm permettent de manipuler ces données de façon extérieures. Pensez à lire le manuel, c'est très court et vous pourrez en profiter pour monitorer les données en question.

Communication avec le processus

Enfin, un processus est isolé et communique avec le reste du monde de très peu de façons différentes :

• avec des file descriptor (réseau, fichier, pipe, tty, device ...)
• à travers la mémoire partagée et les IPC
• avec des signaux
• par la ligne de commande (en lecture seule)
• et avec quelques appels système ayant une action sur le système lui-même

Une PKI (Public Key Infrastructure), en français IGC (Infrastructure de Gestion des Clés) est un système permettant de gérer des clés publiques. Il s'agit en général de gérer des certificats x509. Elle établit un réseau de confiance entre utilisateurs, lequel passe nécessairement par l'autorité de certification.

Ces certificats peuvent servir selon leur contenu à :

• Chiffrer (des communications)
• Signer (des documents)
• S'authentifier (sur des applications)
• Certifier d'autres clés

Disposer d'une PKI signifie qu'on est capable de créer, pour chacun de ses utilisateurs, des certificats qui nous permettront par la suite de lui faire confiance. Pour cela une PKI offre plusieurs services :

• Un service d'enregistrement qui vérifie l'identité des "utilisateurs"
• Un service de signature de demande de certificats
• Un service de renouvellement de certificats
• Un service de publication des certificats
• Un service de révocation des certificats
• Un service de publication des révocations
• Parfois un service de création de clés

Ces fonctionnalités sont généralement regroupées dans des entités séparées pour des raisons de sécurité. En effet, une PKI une fois en place devient rapidement un élément critique puisqu'elle permet de se faire passer pour une entité digne de confiance (pensez social engineering mais sans le social) . C'est pourquoi un certain nombre de fonctionnalités peuvent être installés dans un équipement dédié (un HSM, hardware security module). Du coté utilisateur, on peut faire pareil, sauf qu'on appel cet appareil dédié une carte à puce.

Mettre en place une PKI est une chose assez lourde. Mais elle devient intéressante à partir du moment où on se retrouve à gérer un grand nombre de certificats (beaucoup de serveurs ou beaucoup d'utilisateurs). Vous n'avez pas envie d'installer une PKI pour vous authentifier sur un seul serveur. Mais si vous avez 200 000 employés et que vous voulez que tout le monde signe ses mail en x509, il est temps d'en installer une.

Je voudrais attirer votre attention sur le fait qu'il ne s'agit pas seulement de créer des certificats et de les signer. La confiance se fait sur toute une chaîne, et il faut pouvoir garantir que l'autorité n'a pas été compromise (AC séparée). Il faut pouvoir garantir cette confiance dans le temps (renouvellement), il faut pouvoir se prémunir des erreurs, des vols ou des changements d'organisation (révocation). C'est pourquoi il est nécessaire de prendre son temps avant de l'installer pour bien comprendre le fonctionnement de chaque élément.

Il existe plusieurs PKI open source dont EJBCA ou NewPKI. Je parlerai d'OpenSSL, la PKI du pauvre, dans mes prochains articles. Principalement pour pouvoir mettre les mains dans le cambouis, ne pensez pas à l'utiliser tel quel comme PKI.

Il arrive régulièrement d'avoir à développer des expressions régulières. Si on excepte grep et sed, la plupart des outils utilisant des expressions régulières sont compatibles perl (en utilisant PCRE). C'est donc un bon point. Apprendre les expression régulières (qu'on peut considérer comme un langage à part entière) ne sera pas perdu même si on change d'outil ou de langage.

Tests

Avant de développer une expression régulière, je vous propose de vous familiariser avec le test de ces expressions. Si vous avec une ligne de commande c'est tout simple, hop un test ligne par ligne :

$ perl -pe 's/expression/########/'
données
a matcher, 
autant que vous voulez
<ctrl-d>

Mais si vous préférez un interface plus évoluée : voici un des nombreux qui permettent de tester vos expressions en direct http://myregexp.com/ et avec coloration des éléments matchés.

Syntaxe de base

Une expression régulière, c'est une chaîne de caractère qui a pour but de repérer des informations dans un texte. Elles sont en général implémentées sous forme d'automates à état finis. Cette méthode est extrêmement efficace et dans la plupart des cas il est très difficile de faire plus rapide.

Cette chaîne peut être utilisée pour chercher des informations dans un texte, mais aussi pour faire des remplacements automatisés. Perl utilise une syntaxe autour des expressions régulières pour préciser comment les utiliser. Celle-ci est souvent reprise par les utilisateurs des PCRE mais ca n'a rien d'obligatoire :

• /expression/ : pour faire des recherches
• s/expression/remplacement/ pour faire du recherche/remplacer
• y/expression/remplacement/ pour faire des substitutions de caractères

y/// est un cas particulier que nous ignorerons.

Chacune de ces chaînes peut être suivie par un modificateur. Le plus utile est /i qui permet de ne pas se soucier de la casse. Exemple : /toto/i matchera ToTo. Le deuxième plus important est /g qui permet de faire le remplacement autant de fois que c'est possible et non pas seulement la première fois que l'expression matche.

Attention, hors perl, il se peut que tout ceci ne soit pas valable, mais cela ne change rien quant à la syntaxe des expressions expliquée ci après.

Syntaxe des expressions

Le principe d'une expression régulière (abrégé en regex) est de matcher des milliers de possibilités sans devoir toutes les écrire. Il ne s'agit donc (quasiment) que de "raccourcis".

Donc commençons par les non-raccourcis :

• () : les parenthèses ont deux fonctions, grouper des éléments entre eux et mémoriser le contenu matché pour le rendre réutilisable par la suite
• | : opérateur OU comme dans "confiture ou nutella ?"

Exemples :

^vive (la confiture|le nutella)$

Maintenant les raccourcis :

• . : n'importe quel caractère
• ^ $ : début et fin de chaîne
• [abf] : a ou b ou f
• [a-m] : a ou b ou ... ou m
• [^a b] : tout sauf a ou espace ou b
• \d : un chiffre
• \w : un caractère alphanumérique
• \W : un caractère non alphanumérique
• \s : un caractère d'espacement
• \S : un caractère de non-espacement
• a? : 0 ou 1 fois a
• b+ : 1 ou plus fois b
• c* : 0 ou plus fois c
• d{3} : 3 fois d
• ...

Il y en a plein d'autres, mais avec celles-ci vous saurez vous débrouiller dans la plupart des situations.

Exemples :

# récupérer le hostname d'un nom de domaine dans $1
(\w+)(\.\w+)*
# récupérer une heure/minute/seconde en début de ligne dans $1, $2 et $3
^(\d\d):(\d\d):(\d\d)\s
# matche une ligne variable="valeur" avec ou sans guillemets et des espaces autorisés
^\s*(\w+)\s*=\s*"?(.*)"?

Après cette petite initiation sans conséquences, vous pouvez aller lire la vraie documentation fournie en manpage avec la documentation perl man perlre.