[Cours système Linux – Episode 1] Introduction

Le savoir que nous allons aborder dans ce cours système Linux fonctionne en réalité dans n’importe quel environnement Unix.

Unix est un système d’exploitation multi-processus et multi-utilisateurs inventé dans les années 60. Historiquement, il s’est rapidement séparé en deux familles d’Unices (c’est le pluriel d’Unix) : System V, plutôt porté par le monde industriel, et BSD porté par l’Université de Berkeley. Les unices d’aujourd’hui ont fini par être compatible de ces deux mondes.

Est un Unix tout système d’exploitation conforme au standard Posix qui définit ce qu’est un Unix. Si demain je me mets devant mon ordi et que je programme de zéro un OS conforme à cette norme, alors mon OS est de facto un Unix.

Du coup beaucoup d’entreprises commerciales ont créé leur Unix. On peut citer par exemple Sun Microsystems avec son Unix Solaris, très connu dans l’industrie et dans les universités, Silicon Graphics avec son Unix Irix (une tuerie), IBM avec son Unix AIX, Hewlett-Packard avec son Unix HP-UX, Apple avec son Unix MacOS (eh oui), SCO avec son Unix SCO Unix, etc.

Quelques passionnés ont également développé des implémentations libres et gratuites d’Unix. On peut citer Linux, qui est bien un Unix pur et dur parfaitement compatible Posix, même si on a tendance à ne pas le savoir. Il y a aussi FreeBSD, OpenBSD, NetBSD et d’autres encore.

Bref, bien qu’à partir de maintenant nous ne parlerons plus que de Linux, ce que nous allons voir dans ce cours système en termes d’appels systèmes marche dans n’importe quel Unix.

Architecture d’une machine tournant sous Linux

Lorsqu’une machine Linux boote, le premier programme a prendre place en mémoire est le Noyau (Kernel en anglais). Ce noyau se positionne dans une zone mémoire à haut privilège, a tel point qu’il n’y a plus que lui qui peut accéder au matériel présent sur la machine.

Les autres programmes sont lancés ensuite, mais résident dans des zones mémoire de moindre privilège. Eux n’ont aucun droit d’accéder au matériel sans passer par le noyau.

L’interface graphique de la machine, appelée X Window, qui au passage est aussi standardisée d’un constructeur à l’autre à tel point qu’il est très facile sous Unix de lancer un programme sous Linux par exemple et de le faire apparaître sur la machine Solaris qui est à côté, n’est finalement qu’un programme comme un autre.

L’idée générale est que les applications doivent faire des « appels systèmes » au noyau pour pouvoir accéder au matériel. La notion d’accès au matériel est très élastique puisque la simple ouverture d’un fichier est un accès au matériel. En fait, on voit bien que sans accès au matériel on ne peut quasiment rien faire dans un programme.

Les programmes passent donc leur temps à faire des appels systèmes au noyau, et les programmeurs qui codent ces programmes connaissent les appels systèmes qu’ils utilisent sur le bout des doigts.

Passer par le noyau pour accéder au matériel n’a que des avantages. D’une part, le code exécuté lors d’un accès au matériel est donc de facto du code écrit dans le noyau. Les programmeurs de noyau Unix étant les meilleurs du monde, on a affaire à du code sûr, sans danger pour la machine.

D’autre part, le passage obligatoire par le noyau rend le contrôle des autorisations par celui-ci possible. Ce n’est en effet pas parce que je fais un appel système au noyau que j’avais le droit de le faire. Si je tente d’accéder à un fichier qui ne m’appartient pas par exemple et que le propriétaire légitime du fichier a positionner les droits dessus pour protéger son fichier, le noyau se rendra compte que je n’ai pas le droit de faire ce que je demande et refusera.

Dernier avantage : étant donné qu’aucun programme ne peut acquérir autant de droits que le noyau, l’écriture de virus informatiques pour le monde Unix est très compliquée, du moins avec les mécanismes habituellement utilisés sous Windows.

Ce qui fait que les virus marchent très bien sous Windows, pour en avoir programmé dans ma jeunesse, c’est qu’il est assez facile de détourner les privilèges du noyau au profit du virus, le rendant ainsi par exemple furtif. Sous Unix c’est en théorie impossible, aucun programme ne peut piquer les super droits au noyau.

En pratique, il existe des virus sous Linux (ou sur Mac) c’est indéniable. Leur existence est permise essentiellement par deux phénomènes. Primo, il est facile d’écrire un code auto-générateur qui respecte les droits. Le virus sera donc contenu uniquement sur l’utilisateur qui l’a introduit sur la machine, et ce tant qu’aucun imbécile ne lancera un des programmes infectés en utilisant le compte de l’administrateur (root). Facile à écrire mais propagation rarissime. Secundo, utiliser une faille de sécurité inconnue sur le système (il y en a malheureusement dans tout système) pour acquérir les droits de root. Une fois le droit administrateur atteint, c’est open bar pour une propagation de code malveillant.

Sauf que ce n’est pas donné à tout le monde de connaître et exploiter ces failles, d’autant qu’on est ici sur un noyau open source, remis à jour régulièrement.

Bref, vous avez compris que, vu la structure utilisée sous Linux, il est impossible de devenir un programmeur Linux sans connaître les appels système utilisables pour discuter avec le noyau.

L’étude de ces appels système est le cours système Linux.

Nous allons donc, dans une série d’articles, voir les différents appels systèmes à connaître, et les mécanismes noyau qui sont derrière, mais il est bien évident qu’on ne pourra pas balayer les quelques 200 appels systèmes.

Généralement le programmeur utilise une sorte de bible de référence. En ce qui me concerne, je recommande fortement le cours système Linux de Christophe Blaess qui est une pointure dans le domaine et qui a produit ce qui se fait de mieux en terme de bible.

Tagués avec : , , ,

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.

Résoudre : *
20 + 27 =