![[Home]](http://wiki.linux-vserver.org/skins/common/images/wiki.png)
We currently migrate to MediaWiki from our old installation, but not all content has been migrated yet. Take a look at the Wiki Team page for instructions how to help or browse through our new wiki at wiki.linux-vserver.org to find the information already migrated.
Ce chapitre décrit les modifications à apporter au noyau pour implémenter un mécanisme comme Linux-VServer.
La séparation telle que décrite dans la partie 'Concepts' nécessite quelques modifications au noyau pour permettre la notion de Contexte.
Le but d'un tel "Contexte" est de cacher à un processus tout ce qui ne doit pas etre à sa portée, et empécher les interractions indésirables entre un processus appartenant à un contexte et un processus appartenant à un autre contexte.
Cette séparation nécessite l'extension d'un certain nombre de structures de données pour qu'elles prennent en compte les contextes et fassent la différentiation entre deux uids identiques mais utilisés dans deux serveurs virtuels différents.
De plus, nous avons besoin d'un contexte par defaut qui sera utilisé par le serveur hôte au démarrage, et pour éviter les problèmes liés à des suppositions érronées de certains outils en espace utilisateur (comme pstree) par exemple, l'idée comme quoi init existe toujours et a toujours l'uid 1.
Pour simplifier l'administration, le Contexte de l'Hôte n'est pas traité différemment d'un autre contexte, en tout cas du point de vue de l'isolation des processus.
Pour avoir un apercu global de tous les processus, un Spectateur spécial a été mis en place, qui est capable de capturer tous les processus d'un coup.
Voir les Examples [E21],[E22] et [E23]
Bien que les Contextes soient suffisant pour isoler un groupe de processus, un autre type d'isolation, ou plutot une limitation, est nécessaire pour confiner les processus dans un sous ensemble d'adresses réseau disponibles.
Plusieurs problèmes doivent être pris en compte dans ce sens: par exemple, les appels système bind sur IPADDR_ANY doivent être traités d'une manière bien particulière.
Actuellement, Linux-Vserver n'utilise pas les interfaces virtuelles (et ne les utilisera peut-être jamais), pour minimiser le cout supplémentaire qu'elles engendrent. De ce fait, l'attachement d'une socket et la transmission des packets ont été adaptés.
Voir Example [E24]
Un problème majeur avec le chroot() de Linux aujourd'hui tient au fait que cette information est volatile, et changera au prochain appel système de chroot().
Voici une façon simple pour sortir d'un environnement chrooté Créez tout d'abord un fichier, et retenez son descripteur. Puis chrootez dans un répertoire au même niveau ou un niveau au dessous de celui-ci. Cela a pour effet de faire descendre la racine' dans le système de fichiers. Ensuite, faites un appel à fchdir() sur le descripteur de fichiers pour sortir de cette nouvelle'' racine. Vous sortirez en même temps de l'ancienne racine, qui a été perdue suite au dernier appel système chroot().
Alors que des méthodes exotiques étaient utilisées dans les anciennes versions de Linux-Vserver pour fixer ce problème, les versions récentes utilisent un marquage spécial, connu sous le nom de Barrière Chroot, placé sur le parent de tous les VPS pour prévenir toute modification non autorisée et sortie du confinement.
L'implémentation actuelle des capacités Linux ne prend pas en compte les capacités POSIX sur les systèmes de fichiers. Si cela était le cas, les executables setuid et setgid seraient sécurisés. Pour conserver donc une bonne sécurité malgré cette contrainte, nous avons défini un plafond pour tous les processus d'un même contexte, et un masque de capacités additionnel pour chaque contexte a été aussi ajouté pour limiter à ce seul masque les processus qui appartiennent à ce contexte.
La signification des capacités individuelles (bits) pour ce masque est exactement identique à celui que permet l'ensemble des capacités.
La plupart des ressources sont d'une certaine manière partagées à travers les différents contextes; certaines requièrent une isolation plus importante que les autres, soit pour éviter les problèmes de sécurité, ou pour permettre une meilleure comptabilité de l'usage des ressources;
Ces ressources sont:
Bien qu'elle puisse être totalement desactivée, cette modification est requise pour une meilleure robustesse au niveau du système de fichiers, et pour isoler les contextes. Le drapeau XID est aussi totalement indispensable pour implémenter le support pour les Limites Disques par Contexte et les Quotas par Contexte sur une partition partagée.
Ce concept d'ajouter un identifiant de contexte (xid) à chaque fichier pour créer une notion d'appartenance d'un fichier à un contexte parait simple ... Il n'en est rien, car l'implémentation actuelle n'est pas triviale. Elle nécessite soit une modification des représentations du système de fichier, soit des astuces au niveau applicatif.
Une approche non intrusive pour éviter toute modification du système de fichiers sous-jacent est d'utiliser les bits de poids forts de champs existants, comme ceux des UID ou GID pour stocker le XID additionnel.
Une fois que les informations de contexte sont disponibles au niveau de chaque inode, l'étape logique suivante est d'étendre la vérification d'accès au contexte en plus du reste.
Actuellement, tous les acces aux inodes sont vérifiés par rapport à leur contexte ID, à l'exception des contextes "Hôte" et "Spectateur".
Les fichiers non étiquettés dans le contexte hôte sont simplement traités comme appartenant au contexte courant, et cela est requis pour que l'Unification soit possible. Si un tel fichier est modifié à l'intérieur d'un contexte, elle changera en silence vers son noveau contexte, en changeant son XID.
Les méthodes suivantes de marquage sont utilisées:
Avantage: Valeurs 32bit uid/gid complètes.
Avantage: fonctionne avec tout système de fichiers équipé de UID / GID 32bits
Désavantage: le GID est réduit a 16 bits.
Avantage: fonctionne sur tout système de fichiers avec des UID/GID 32bits
Desavantage: les UID et GID sont réduits a 24 bits.