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.
Nous savons maintenant que Linux-VServer implémente quelques principes de sécurité, et comment ils fonctionnent. Il faut tout de même dire quelques mots la dessus, puisqu'il ne suffit pas, bien évidemment, de considérer que Linux-VServer étant une architecture sécurisée, votre système sera sur automatiquement. Comme d'habitude, mieux vaut savoir *exactement* ce que vous faites.
Actuellement, seules les Caps Linux suivantes sont considérées d'un usage sans risque dans un VPS. Si d'autres capacités sont nécessaires, elles ouvrent probablement des trous de sécurité.
CAP_NET_RAW par exemple n'est pas considéré comme sur. Bien qu'il soit souvent utilisé pour donner le droit à la commande "ping" (dont le fonctionnement est cassé), il existe de bien meilleures alternatives comme la commande ping "poink[U7]", ou la cap VXC_RAW_ICMP.
Il faut vous assurer que le drapeau barrière est bien mis sur tout répertoire parent de chacun de vos VPS. Cela est indispensable pour prévenir quiconque de sortir du chroot et aller se balader dans le système de fichier de votre vserver hôte.
Le répertoire /dev d'un VPS ne doit pas contenir plus de fichiers qu'indiqué ci-dessous, plus le répertoire pour les pts unix.
Of course other device nodes like console, mem and kmem, even block and character devices can be added, but some expertise is required in order to ensure no security holes are opened.
There has been no detailed evaluation of secure and unsecure entries in the proc filesystem, but there have been some incidents where unprotected (not protected via Linux Capabilities) writable proc entries caused mayhem.
For example, /proc/sysrq-trigger is something which should not be accessible inside a VPS without a very good reason.