![[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 a un processur tout ce qui ne doit pas etre a 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 hote au démarrage, et pour éviter les problèmes liés à des suppositions éronné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'Hote 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 facon simple pour sortir d'un environnement chrooté Créez tout d'abbord 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 a 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.
Because the current Linux Capability system does not implement the filesystem related portions of POSIX Capabilities which would make setuid and setgid executables secure, and because it is much safer to have a secure upper bound for all processes within a context, an additional per-context capability mask has been added to limit all processes belonging to that context to this mask.
The meaning of the individual caps (bits) of the capability bound mask is exactly the same as with the permitted capability set.
Most resources are somewhat shared among the different contexts; some require additional Isolation than others, either to avoid security issues or to allow for improved accounting.
Those resources are:
Although it can be disabled completely, this modification is required for more robust filesystem level security and context isolation. It also is mandatory for Context Disk Limits and Per Context Quota Support on a shared partition.
The concept of adding a context id (xid) to each file to make the context ownership persistent sounds simple, but the actual implementation is non-trivial - mainly because adding this information either requires a change to the on disk representation of the filesystem or the application of some tricks.
One non-intrusive approach to avoid modification of the underlying filesystem is to use the upper bits of existing fields, like those for UID and GID to store the additional XID.
Once context information is available for each inode, it is a logical step to extend the access controls to check against context too.
Currently all inode access restrictions have been extended to check for the context id, with special exceptions for the Host Context and the Spectator Context.
Untagged files belong to the Host Context and are silently treated as if they belong to the current context, which is required for Unification. If such a file is modified from inside a context, it silently migrates to the new one, changing its xid.
The following Tagging Methods are implemented:
See Examples [E31] and [E32]