Paper/fr

Abstract

Concept logiciel basé sur les Security Contextes permet la création d'une multitude de serveurs virtuels Privés (VPS) tournant simultanément sur un même serveur physique à pleine vitesse, en partageant efficacement les ressources matérielles. Un VPS offre un environnement quasiment identique à celui d'un serveur Linux conventionnel. Tous les services, comme ssh, mail, Web, bases de données, peuvent être lancés dans un tel VPS, sans aucune modification (ou, dans certains cas, des modifications mineures), exactement comme avec n'importe quel autre serveur réel.

Chaque serveur virtuel possède sa propre base utilisateurs et son mot de passe root. Il est isolé de tous les autres serveurs virtuels, sauf en ce qui concerne les ressources matérielles, qui sont partagées par tous les serveurs virtuels.

Introduction

Au fur et à mesure des années, les micro ordinateurs sont devenus suffisemment puissant pour utiliser la virtualisation comme méthode pour donner l'illusion d'avoir une multitude de petites machines virtuelles, chacune d'elle tournant avec une instance différente de n'importe quel système d'exploitation.

Il existe plusieurs types de Machines Virtuelles (VMs) dont les fonctionnalités sont similaires, mais qui diffèrent dans le degré d'abstraction et les méthodes utilisées pour la virtualisation.

La plupart d'entre elles "émulent" une ressource matérielle réelle ou fictive, qui, à son tour, fait usage de "vraies" ressources du système Hote (la machine qui fait tourner les VMs). Cette approche, utilisée par la plupart des émulations système (comme QEMU[U1], Bochs[U2], ... permet à l'émulateur d'éxécuter n'importe quel système d'exploitation, même pour une architecture différente (CPU et matérielle). Pas besoin de modifier le système d'exploitation Invité, puisqu'il n'est pas conscient de s'éxécuter sur autre chose qu'un vrai matériel.

Quelques émulations systèmes ont besoin d'un petit nombre de modifications ou de pilotes de périphériques spécifiques sur le système Hote ou le système Invité pour améliorer les performances, et minimiser le grignotage superflu de ressources système qui passe dans les systèmes de cache et de médiation entre le système Hote et le système Invité. Bien que cela améliore sensiblement l'efficacité de ces solutions, les ressources perdues sont toujours notables (par exemple dans UML[U3] et Xen[U4]).

Supposez par contre que les systèmes d'exploitation à lancer ne sont pas différents ... La plupart des applications qui tournent sur un serveur n'ont pas besoin d'acceder au matériel ou à du code au niveau noyau, et pourraient donc partager une machine avec les autres, si l'on pouvait les séparer et les isoler ...

Le Concept

A la base, un serveur Linux est constitué de trois blocs constitutifs: Le matériel, le Noyau, et les Applications. Le Matériel dépend habituellement du fournisseur ou de l'administrateur système, et, bien qu'ayant une grande influence sur les performances globales, ne peut pas être changé facilement, et diffère sensiblement d'une configuration à l'autre.

Un role de base du noyau consiste à créer une couche d'abstraction au dessus du matériel pour permettre aux processus (Applications) de travailler avec des ressources (Données) sans connaitre les détails du matériel qui se trouve en dessous. Idéalement, ces processus sont complètement agnostiques vis-à-vis du matériel, écrit dans un langage interprété, et ne nécessitant par conséquent aucun savoir faire spécifique au matériel.

Puisqu'un système possède assez de ressources pour faire tourner environ dix fois plus d'applications que nécessaire sur un serveur Linux traditionnel, pourquoi ne pas placer sur celui-ci une dizaine de serveurs, qui vont partager les ressources d'une manière efficace ?

La plupart des serveurs d'application (par exemple httpd) considère qu'il est la seule application à fournir un service particulier, et d'habitude, va donc supposer une organisation particulière au niveau du système de fichiers, et de l'environnement. Cela implique que deux services identiques tournant sur un même serveur physique, mais différent simplement au niveau de leur adresse IP, par exemple, doivent être coordonnées. Cela demande typiquement pas mal de boulot pour l'administrateur système, et cela peut conduire à un stabilité réduite du système et de la sécurité.

Le concept de base de la solution Linux-VServer est de séparer l'environnement en user space (espace utilisateur) en trois unités distinctes (appellées parfois VPS, ou Virtual Private Server), de telle manière que chaque VPS ressemblera à un vrai serveur vis-à-vis des processus qu'il contient.

Bien que différentes Distributions Linux utilisent des noyaux modifiées (parfois lourdement) pour assurer le support de telle ou telle fonctionnalité, ou matériel, la plupart des distributions Linux ne sont pas liées irrévocablement à un noyau linux particulier.

Linux-VServer utilise cela pour donner à plusieurs distributions, la possibilité de se lancer au dessus d'un seul noyau, partagé, sans accès direct au matériel, et partager les ressources d'une manière très efficace.

Infrastructure Existante

Les noyaux Linux récents fournissent déjà de nombreuses fonctions de sécurité qui sont utilisées par Linux-Vserver pour fonctionner, telles que le Système de Privileges Linux, les limites de ressource, les attributs de fichier et l'environnement chroot. Les sections suivantes vous donneront un court aperçu de chacune d'entre elles.

Le système de Privileges (Capabilities) Linux

En science informatique, un privilege est un jeton utilisé par un processus pour prouver qu'il est autorisé à faire une opération sur un objet. Le Système de privileges Linux est basé sur les "Privileges POSIX", un concept légèrement similaire, conçu pour diviser les privilèges root puissants en un ensemble de privilèges distincts.

Privileges POSIX

Un processus possède trois champs de bits appelés les privileges héritables (I - "Inheritable"), permises (P), et effectives (E). Chaque privilege est implémenté dans un bit de chacun de ces champs, bit qui est soit défini soit non-défini.

Quand un processus essaie de faire une opération privilégiée, le système d'exploitation va vérifier les bits appropriés dans l'ensemble effectif des processus (au lieu de vérifier si l'uid respectif du processus est 0 comme il le fait habituellement).

Par exemple, quand un processus essaie de modifier l'horloge, le noyau Linux va vérifier que ce processus a le bit CAP_SYS_TIME (actuellement le bit 25) parmi ses privileges effectives.

L'ensemble permis d'un processus indique les privileges que celui-ci peut utiliser. Le processus peut avoir des privileges définies dans l'ensemble permis qui ne sont pas dans l'ensemble effectif.

Ceci indique que le processus a temporairement désactivé ce privilege. Un processus n'est autorisé à définir un bit dans son ensemble effectif que si ce bit est disponible dans son ensemble permis.

La distinction entre privileges effectif et permis existe pour que les processus puissent réaliser des opérations qui nécessitent des privilèges.

Les privileges héritables sont les privileges du processus courant qui peuvent être hérités par un programme exécuté par ce dernier. L'ensemble permis d'un processus est masqué contre l'ensemble héritable pendant exec().

Rien de spécial ne se produit durant fork() ou clone().

Les processus fils ou les threads obtiennent une copie exacte des privileges du processus parent.

L'implémentation dans Linux s'arrête là, alors que les privileges POSIX[U5] requièrent l'ajout d'un ensemble de privileges aux fichiers, pour remplacer le flag SUID (au moins pour les exécutables).

Vue d'ensemble des privileges

La liste des privileges POSIX utilisées avec Linux est longue, et les 32 bits disponibles sont presques tous utilisés. Bien que la liste détaillée de ces privileges puisse être trouvée dans /usr/include/linux/capability.h sur la plupart des systèmes Linux, une vue d'ensemble des privileges importantes est donnée ici.

0	CAP_CHOWN	change le propriétaire et le groupe du fichier
5	CAP_KILL	envoie un signal au processus avec un ID utilisateur différent, réel ou effectif
6	CAP_SETGID	permet le passage de setgid(2), setgroups(2), et de gids forgés sur les sockets
7	CAP_SETUID	permet le passage de set*uid(2) et d'uids forgés sur les sockets
8	CAP_SETPCAP	transfert/déplace tout privilege de l'ensemble permis vers/depuis n'importe quel pid
9	CAP_LINUX_IMMUTABLE	permet la modification des attributs de fichier S_IMMUTABLE et S_APPEND
11	CAP_NET_BROADCAST	permet la diffusion et l'écoute en multicast
12	CAP_NET_ADMIN	permet la configuration de l'interface, le pare-feux IP, le masquerading, l'accounting, le débugage de sockets, les tables de routage, la liaison sur n'importe quelle adresse, l'entrée dans le mode de promiscuité, le multicasting...
13	CAP_NET_RAW	permet l'utilisation des sockets RAW et PACKET
16	CAP_SYS_MODULE	ajoute et retire des modules noyau
18	CAP_SYS_CHROOT	permet chroot(2)
19	CAP_SYS_PTRACE	permet ptrace() sur n'importe quel processus
21	CAP_SYS_ADMIN	la liste serait trop longue, ceci permet en gros de faire tout ce qui n'est pas mentionné dans les autres privileges
22	CAP_SYS_BOOT	permet reboot(2)
23	CAP_SYS_NICE	permet l'élévation des privilèges et la modification de la priorité des autres processus, en modifiant l'ordonnanceur
24	CAP_SYS_RESOURCE	passe outre les limites de ressource, de quota, l'espace réservé sur un système de fichier...
27	CAP_MKNOD	permet les aspects privilégiés de mknod(2)

Voir également les Exemples [E01],[E02], et [E03].

Limite des Ressources

Vous pouvez limiter les ressources de chaque processus en spécifiant une limite pour chaque ressource. A la manière des privileges Linux, il existe deux types de limites, l'une Douce, l'autre Dure.

La limite Douce est la valeur que le noyau imposera pour cette ressource à un processus. Un utilisateur non privilégié pourra régler la limite Douce n'importe où en dessous de la valeur Dure. Seul l'utilisateur root pourra re-hausser la limite Dure.

Apercu des Ressources Limit-ables

La liste des ressources qui peuvent être limitées se trouve dans le fichier /usr/include/asm/resource.h sur la plupart des systèmes Linux.

0	RLIMIT_CPU	Temps CPU en secondes. un signal SIGXCPU est envoyé au processus qui a atteind la limite Douce, et un SIGKILL pour la limite Dure.
4	RLIMIT_CORE	Taille maximale d'un fichier core.
5	RLIMIT_RSS	Nombre de pages maximum qu'un processus peut utiliser (en RAM)
6	RLIMIT_NPROC	Nombre maximum de processus autorisés à l'utilisateur réel du processus appelant.
7	RLIMIT_NOFILE	Spécifie la valeur +1 pour le nombre maximum de descripteurs de fichiers ouvert par un processus.
8	RLIMIT_MEMLOCK	Nombre maximum de pages mémoire virtuelle autorisées à être vérouillées en RAM à l'aide des appels mlock() ou mlockall().
9	RLIMIT_AS	Nombre maximum de pages de mémoire virtuelle disponible pour un processus.

(Limite de l'espace d'adressage)

Voir aussi les Exemples [E11], et [E12].

Attributs de Fichiers

Auparavant, cette fonctionnalité n'était disponible qu'avec ext2, mais maintenant tous les systèmes de fichiers majeurs implémentent un ensemble d'Attributs de fichiers de base, qui permettent le paramétrage de certaines propriétés. Voici de nouveau un bref aperçu des possibilités des attributs, et leur signification.

s SECRM	Lorsqu'un fichier avec cet attribut est détruit, les blocs qui le composent sont mis à zéro et re-écrit sur le disque.
u UNRM	Lorsqu'un fichier avec cet attribut est détruit, son contenu est sauvegardé.
c COMPR	Un fichier marqué avec cet attribut est automatiquement compressé à l'écriture et décompressé à la lecture. (pas encore implémenté)
i IMMUTABLE	Un fichier avec cet attribut ne pourra pas être modifié: Impossible de le renommer ou de le détruire, impossible de créer un lien vers ce fichier, ni d'écrire une donnée de plus vers ce fichier.
a APPEND	Un fichier avec cet attribut ne pourra être ouvert qu'en mode ajout.
d NODUMP	Si cet attribut de fichier est mis, le fichier n'est pas candidat à un backup via l'utilitaire "dump".
S SYNC	Les mises à jour vers ce fichier se feront de manière synchrone.
A NOATIME	Empêche la mise à jour de l'enregistrement atime lors d'un accès ou d'une modification de fichier.
t NOTAIL	Un fichier avec l'attribut t n'aura pas de fragment bloc en fin de fichier fusionné avec un autre fichier.
D DIRSYNC	Les modifications apportés à ce répertoire seront écrites de manière synchrones.

Voir aussi les Exemples [E13] et [E14].

La Commande chroot(1)

chroot permet de lancer une commande en changeant le répertoire racine dans lequel il va s'éxécuter. Cela signifie que tout parcours du système de fichiers à partir de la racine '/' se fera à partir de la racine substituée et non pas à partir de la racine originelle.

Bien que le chroot Linux n'est pas très sécurisé, son utilisation augmente l'isolation des processus par rapport au système de fichier, et, à condition de l'utiliser correctement, peut être utilisé pour "emprisonner" un processus, un utilisateur unique, ou un démon (service).

Voir l'Exemple [E15]

Modifications Requises

Ce chapitre décrit les modifications à apporter au noyau pour implémenter un mécanisme comme Linux-VServer.

Séparation de Contextes

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]

Séparation Réseau

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]

La Barrière Chroot

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.

Un plafond pour les Privileges

L'implémentation actuelle des privileges Linux ne prend pas en compte les privileges 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 privileges additionnel pour chaque contexte a été aussi ajouté pour limiter à ce seul masque les processus qui appartiennent à ce contexte.

La signification des privileges individuels (bits) pour ce masque est exactement identique à celui que permet l'ensemble des privileges.=== Isolation de Ressources ===

Isolation de Ressources

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:

mémoire partagée, IPC
PID et User ID
Drapeau xid sur les fichiers
ptys Unix
sockets

Drapeau XID pour les Filesystem XID

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:

UID32/GID32 or EXTERNAL: Ce format utilise l'espace inutilisé dans l'inode disque pour stocker les informations de contexte. Pour l'instant, c'est uniquement défini pour ext3/ext3, mais sera dans le futur aussi défini pour xfs, reiserfs, et jfs, dès que possible.

Avantage: Valeurs 32bit uid/gid complètes.

UID32/GID16: Ce format utilise la moitié haute du GID pour stocker les informations de contexte. Cela est fait de manière transparente, sauf si le format est changé sans conversion préalable.

Avantage: fonctionne avec tout système de fichiers équipé de UID / GID 32bits

Désavantage: le GID est réduit a 16 bits.

UID24/GID24: Ce format utilise le premier quart haut de l'UID et du GID pour stocker les informations de contexte, une fois encore, d'une manière transparente. Cela permet 16 millions de groupes et utilisateurs, ce qui devrait suffire pour la majorité des applications.

Avantage: fonctionne sur tout système de fichiers avec des UID/GID 32bits

Desavantage: les UID et GID sont réduits a 24 bits.

Voir Examples [E31] et [E32]

Modifications Supplémentaires

En plus du strict minimum, voici un certain nombre de modifications, non indispensables, mais qui se sont révélées très utiles au fil du temps.

Drapeaux par Contexte

Très tôt, le besoin d'activer ou désactiver une fonctionnalité séparement pour l'un ou l'autre des Vserver est apparue. Un champ de bits a donc été ajouté (taille=word).

Ce champ de bits comprend un bon nombre de drapeaux, un champ masque, qui indique les drapeaux disponibles, et un mécanisme de déclanchement spécial, pour activer un drapeau au démarrage, puis le désactiver en causant un évennement ou une action associée.

Voici la liste des drapeaux prévus et pour la plupart déjà implémentés. Ils sont disponibles dans la branche de développement de Linux-VServer:

0	VXF_INFO_LOCK (historique, obsolète)
1	VXF_INFO_SCHED (historique, obsolète)	schedule all processes in a context as if they where one.
2	VXF_INFO_NPROC (historique, obsolète)	limite le nombre de processus autorisés dans un contexte à la valeur NPROC.
3	VXF_INFO_PRIVATE (historique)	interdiction d'entrer dans ce contexte depuis l'extérieur.
4	VXF_INFO_INIT (historique)	show the init process with pid '1'
5	VXF_INFO_HIDE (historique, obsolète)
6	VXF_INFO_ULIMIT (historique, obsolète)
7	VXF_INFO_NSPACE (historique, obsolète)
8	VXF_SCHED_HARD	activer l'ordonnancement "Hard CPU"
9	VXF_SCHED_PRIO	calculer les priorités de chaque processus à l'aide du "contexte token bucket".
10	VXF_SCHED_PAUSE	mettre tous les processus de ce contexte dans la file "hold", les empéchant d'être ordonnancés à nouveau.
16	VXF_VIRT_MEM	virtualize the memory information so that the VM and RSS limits are used for meminfo and friends
17	VXF_VIRT_UPTIME	virtualiser l'uptime, en commançant à la date de création du contexte.
18	VXF_VIRT_CPU
24	VXF_HIDE_MOUNT	afficher les /proc/{pid}/mounts comme vides.
25	VXF_HIDE_NETIF	cache les interfaces réseau et addresses non autorisées dans ce contexte.

Voir Exemple [XX]

Privileges par Contexte

Lorsque nous sommes arrivé au nombre maximum de privileges envisageables sans trop modifier le noyau, l'étape suivante a été, naturellement, d'ajouter un système de privileges par contexte.

Le mécanisme des privileges par contexte implémenté dans Linux-VServer permet un réglage fin des privileges Linux. Ils ne sont pas visibles aux processus d'un contexte donné, puisque de toute facon le processus n'aurait pas le droit de les vérifier ou de les modifier.

Généralement, il y a deux facons d'utiliser ces privileges : * Require one or a number of context capabilities to be set in addition to a given Linux capability, each one controlling a distinct part of the functionality. For example the CAP_NET_ADMIN could be split into RAW and PACKET sockets, so you could take away each of them separately by not providing the required context capability.

Consider the context capability sufficient for a specified functionality, even if the Linux Capability says something different. For example mount() requires CAP_SYS_ADMIN which adds a dozen other things we do not want, so we define a CCAP_MOUNT to allow mounts for certain contexts.

The difference between the Context Flags and the Context Caps is more an abstract logical separation than a functional one, because they are handled very similar. Again, a list of the Context Capabilities and their purpose:

0	VXC_SET_UTSNAME	autoriser le contexte à changer le nom de serveur et le nom de domaine en utilisant l'appel système noyau approprié
1	VXC_SET_RLIMIT	allow the context to modify the resource limits (within the vserver limits).
8	VXC_RAW_ICMP	allow raw icmp packets in a secure way (this makes ping work from inside)
16	VXC_SECURE_MOUNT	permit secure mounts, which at the moment means that the nodev mount option is added.

Comptabilité par Contexte

Plusieurs propriétés des contextes sont très utiles pour l'administrateur système, que ce soit pour garder un oeil sur les ressources, pour avoir une idée de ce que peut supporter le serveur, ou pour pouvoir facturer d'une manière ou d'une autre au client.

Deux types de propriétés peuvent être comptabilisées, celles dont la valeur courante représente l'état du système (par analogie, prenez la vitesse d'un véhicule), et celles dont la valeur augmente régulièrement avec le temps (comme le kilométrage).

La plupart des valeurs d'état sont limitables, et sont donc traitées d'une façon spécifique, comme cela est décrit dans la section qui suit.

Good candidates for Context Accounting are:

Temps CPU utilisé
Nombre de fork() effectués
Nombre de messages Socket par Type
Nombre de paquets Transmis et Recus

Voir Exemple [E41]

Limites par Contexte

La plupart des ressources système, que ce soit la consommation mémoire, le nombre de processus utilisés, le nombre de descripteurs de fichiers, la bande passante réseau, doivent pouvoir être limitées.

Les limites par contexte permettent, pour chaque valeur limitable, de définir trois types de limites: minimum, soft, et hard(maximum).

A l'heure actuelle, seule les limites hard sont supportées, et seulement une partie d'entre elles sont réellement activées. Voici une liste des limites par contexte actuelles et prévues:

limites sur les processus
limites sur l'ordonnanceur
limites mémoire
limites disques par contexte
quotas user/groupe par contexte

De plus, les limites par contexte gardent trace des valeur maxima atteintes et du nombre de fois ou la limite a été atteinte (hit), pour donner un feedback utile a l'administrateur.

Voir Exemple [E42]

Virtualisation

One major difference between the Linux-VServer approach and Virtual Machines is that you do not have the virtualization part as a side-effect, so you have to do that by hand where it makes sense.

For example, a Virtual Machine does not need to think about uptime, because naturally the running OS was started somewhere in the past and will not have any problem to tell the time it thinks it began running.

A context can also store the time when it was created, but that will be different from the systems uptime, so in addition, there has to be some function, which adjusts the values passed from kernel to user-space depending on the context the process belongs to.

This is what for Linux-VServer is known as Virtualization (actually it's more faking some values passed to and from the kernel to make the processes think that they are on a different machine).

Currently modified for the purpose of Virtualization are:

System Uptime
Host and Domain Name
Machine Type and Kernel Version
Context Memory Availability
Context Disk Space

Voir Exemple [E43]

Sécurité Renforcée

Le mécanisme de sécurité Proc-FS protège les entrées dynamiques du système de fichiers proc, de façon à ce que toutes les entrées ne soient pas vues dans tous les contextes.

Le système est constitué de trois drapeaux pour chaque entrée du Proc-FS: Admin, Watch, et Hide.

Le Drapeau Hide active ou désactive entierement une fonctionnalité, donc toute combinaison associée avec un drapeau Hide à 0 aura donc la signification visible.

Les drapeaux Admin et Watch déterminent ou l'entrée hidden (cachée) reste visible; par exemple, si les drapeaux Admin et Hidden sont mis, seul le Host Contexte (0) sera en mesure de voir cette entrée spécifique.

Voir Exemple [E44] et Voir Exemple [E45]

Kernel Helper

Dans certains cas, il peut être nécessaire de mettre en place un outil en espace utilisateur qui va agir en lieu et place du noyau, lorsque par exemple un processus demande une fonctionnalité disponible sur un serveur réel, mais non disponible dans un contexte.

Le meilleur exemple d'un tel cas est le "Reboot Helper", qui implémente l'appel système reboot(), invoqué depuis l'intérieur d'un contexte en lieu et place du noyau. L'appel sera éxécuté depuis le contexte hôte, qui lancera l'action adéquate, reboot ou un simple halt du contexte en question.

Bien que ce "helper" soit concu pour être flexible et gérer un certain nombre de choses de la même facon, il n'est pas utilisé pour l'instant à autre chose, et pourrait être remplacé dans le futur par une interface par evènement.