![[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]
One major problem of the chroot() system used in Linux lies within the fact that this information is volatile, and will be changed on the next chroot() Syscall.
One simple method to escape from a chroot-ed environment is as follows: First, create or open a file and retain the file-descriptor, then chroot into a subdirectory at equal or lower level with regards to the file. This causes the root to be moved down in the filesystem. Next, use fchdir() on the file-descriptor to escape from that new root. This will consequently escape from the old root as well, as this was lost in the last chroot() Syscall.
While early Linux-VServer versions tried to fix this by "funny" methods, recent versions use a special marking, known as the Chroot Barrier, on the parent directory of each VPS to prevent unauthorized modification and escape from 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]