Linux Attitude

Niveau :
Résumé : /proc/<pid>

Les processus comme je l'ai déjà décrit, forment une grande famille.

La famille processus

Dans la famille processus je voudrais le père

Les processus se reproduisent par fork (Mitose en français). Ce qui veut dire qu'à la genèse il n'y avait qu'un processus que nous ne nommerons pas Adam mais init.

Tous les processus possèdent un identifiant (pid) ainsi qu'un identifiant de processus parent (ppid) permettant de les repérer dans un arbre généalogique (pstree).

Comment reconnait-on le père du fils lors du fork d'un processus ? Uniquement par le code de retour de la méthode fork qui vaut 0 pour le fils et donne le pid du fils au père. En dehors de cela les 2 processus sont rigoureusement identiques.

Dans la famille processus je voudrais la mère

Désolé, il n'y a pas de femme chez les processus, la reproduction est asexuée, mais c'est une idée à creuser ...

Dans la famille processus je voudrais le fils

Lorsqu'un processus forke, en général le père poursuit sa vie comme si de rien n'était, par contre le fils va muter. La mutation génétique chez les processus est bien plus violente que chez les êtres vivants. En effet, le code (l'ADN en français) est intégralement relu et remplacé depuis un nouveau fichier sur le disque. C'est ce qu'on appelle un exec.

Il existe quelques cas de processus qui ne fonctionnent pas comme ceci, mais qui laissent leur père mourir (ingrats !) et qui prennent leur place. C'est le cas des démons (un parricide est-il un démon ?) dont le but est de devenir indépendants (émancipés) et ne plus avoir de problèmes d'adolescence (le tty du père) ou de famille (le groupe de processus).

Dans la famille processus je voudrais le grand-père

Lorsqu'un processus meurt, sa dépouille est remise à son père. Elle est essentiellement constituée de son code de retour.

Lorsque le père est déjà mort, c'est le doyen qui a la charge de récupérer le code de retour, par exemple avec la méthode wait.

Bookmarks:

Niveau :
Résumé : ssh qemu-system -hda /dev/sda

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.

Bookmarks:

Niveau :
Résumé : Raid 10, raid 0+1, raid 5, raid 6

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)

Bookmarks:

Niveau :
Résumé :

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

Bookmarks:

Niveau :
Résumé : cd && git init ; cd /etc && git init

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

Bookmarks:

Niveau :
Résumé : ps ; top ; htop ; atop ;

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

Bookmarks:

Niveau :
Résumé : PKI ; IGC

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.

Bookmarks: