-
Machine virtuelle peut vous offrir la sécurité la plus élevée sans redémarrage, mais les performances les plus faibles.
-
Une autre option, pour une sécurité encore plus élevée qu'une machine virtuelle :démarrez un CD/DVD/clé USB "live" sans accès au disque dur (désactivez temporairement le disque dur dans le BIOS ; si vous ne pouvez pas, au moins ne montez pas le lecteur / ne le démontez pas, s'il est monté automatiquement - mais c'est beaucoup moins sûr)
-
Un docker conteneur est une alternative un peu moins sécurisée à une machine virtuelle complète. La différence cruciale (en termes de sécurité) entre ces deux est probablement que les systèmes exécutés dans docker utilisent en fait le noyau de votre système hôte.
-
Il existe des programmes tels que isolate qui créeront un environnement spécial et sécurisé - cela s'appelle généralement un bac à sable - ceux-ci sont généralement basés sur chroot, avec une supervision supplémentaire - trouvez-en un qui vous convient.
-
Un simple chroot sera le moins sécurisé (surtout en ce qui concerne l'exécution des programmes), bien que peut-être un peu plus rapide, mais ... Vous devrez créer/copier une arborescence racine séparée et utiliser des montages liés pour
/devetc. (voir Remarque 1 dessous!). Donc, en général, cette approche ne peut pas être recommandée, surtout si vous pouvez utiliser unsandboxplus sécurisé et souvent plus facile à configurer. environnement.
Remarque 0 : À l'aspect d'un "utilisateur spécial", comme le nobody compte :cela ne donne presque rien sécurité, bien moins qu'un simple chroot . Un nobody l'utilisateur peut toujours accéder aux fichiers et aux programmes qui ont lu et exécuter autorisations définies pour autre . Vous pouvez le tester avec su -s /bin/sh -c 'some command' nobody . Et si vous avez un fichier de configuration/historique/cache accessible à tous (par une erreur ou une faille de sécurité mineure), un programme fonctionnant avec nobody les autorisations de peuvent y accéder, grep pour les données confidentielles (comme "pass=" etc.) et de bien des façons les envoyer sur le net ou autre.
Remarque 1 : Comme Gilles l'a souligné dans un commentaire ci-dessous, un simple environnement chroot offrira très peu de sécurité contre les exploits visant à l'élévation des privilèges. Un seul chroot a du sens du point de vue de la sécurité, seulement si l'environnement est minimal, composé de programmes dont la sécurité a été confirmée uniquement (mais il reste toujours le risque d'exploiter les vulnérabilités potentielles au niveau du noyau), et tous les programmes non fiables exécutés dans le chroot s'exécutent en tant qu'utilisateur qui n'exécute aucun processus en dehors du chroot. Ce que chroot empêche (avec les restrictions mentionnées ici), c'est la pénétration directe du système sans escalade de privilèges. Cependant, comme Gilles l'a noté dans un autre commentaire, même ce niveau de sécurité peut être contourné, permettant à un programme de sortir du chroot.
Utilisez une machine virtuelle. Rien de moins n'offre pas beaucoup de sécurité.
Il y a quelques années, j'aurais peut-être suggéré un utilisateur chrooté dédié ou quelque chose du genre. Mais le matériel est devenu plus puissant et les logiciels de machines virtuelles sont devenus plus faciles à utiliser. De plus, les attaques standard sont devenues plus sophistiquées. Il n'y a plus aucune raison de ne pas faire tout le chemin jusqu'ici.
Je recommanderais d'exécuter VirtualBox. Vous pouvez configurer la machine virtuelle en quelques minutes, puis installer une distribution Linux à l'intérieur. La seule configuration non par défaut que je recommande est la configuration réseau :créez à la fois une interface "NAT" (pour communiquer avec le monde) et une interface "hôte uniquement" (afin que vous puissiez facilement copier des fichiers vers et depuis l'hôte, et ssh dans la MV). Désactivez l'interface NAT pendant que vous exécutez les programmes de vos élèves¹ ; activez-le uniquement lorsque vous installez ou mettez à niveau des packages logiciels.
Dans la machine virtuelle, créez un utilisateur par étudiant.
¹ Vous pouvez limiter l'interface NAT à une liste blanche d'utilisateurs, mais c'est plus avancé que nécessaire dans une configuration simple et précise.
voici une explication très détaillée de la raison pour laquelle l'utilisation de Chroot est toujours une option très viable, et pourquoi la virtualisation complète du système d'exploitation ou du matériel est particulièrement exagérée dans des scénarios spécifiques.
ce n'est rien de plus qu'un mythe que Chroot n'est pas une fonctionnalité de sécurité. il existe des outils qui construiront automatiquement le système de fichiers chroot pour vous, et Chroot est intégré à de nombreuses applications courantes en tant que fonctionnalité de sécurité utile.
contrairement à la croyance populaire, toutes les situations ne nécessitent pas une virtualisation complète du système d'exploitation ou une simulation complète du matériel. cela peut en fait signifier en avoir plus surface d'attaque pour essayer de couvrir. à son tour, ce qui signifie un système moins sécurisé . (soi-disant pour les administrateurs système moins avertis)
les règles sont assez simples :ne rien mettre dans le chroot qui ne soit pas nécessaire. n'exécutez pas un démon en tant que root. n'exécutez pas un démon comme n'importe quel utilisateur exécutant un démon en dehors du chroot.
supprimez toutes les applications non sécurisées, les binaires setuid, les liens symboliques / liens durs sans propriétaire. remonter les dossiers inutiles en utilisant nosuid, noexec et nodev. construire la dernière version stable du démon en cours d'exécution à partir de la source. et surtout, sécurisez le système de base !