Exécution d'un programme potentiellement dangereux sous Linux

J'écris un programme qui testera des programmes écrits par des étudiants. J'ai bien peur de ne pas pouvoir leur faire confiance et je dois m'assurer que cela ne finira pas mal avec l'ordinateur qui l'exécute.

Je pensais créer un test utilisateur avec un accès limité aux ressources système et exécuter des programmes en tant qu'utilisateur, mais d'après ce que j'ai trouvé sur le net jusqu'à présent, la création d'un système virtuel serait l'option la plus sûre ...

Quelqu'un peut-il m'aider à choisir la bonne approche? La sécurité est une grande préoccupation pour moi. D'un autre côté, je ne veux pas d'une solution trop lourde et qui passe beaucoup de temps à essayer d'apprendre quelque chose dont je n'ai pas vraiment besoin.

• La machine virtuelle peut vous offrir une sécurité maximale sans redémarrage, mais des performances optimales.

• Une autre option, pour une sécurité encore supérieure à celle d’une machine virtuelle: démarrez un CD / DVD / clé USB "en direct" 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 / démontez-le, si monté automatiquement - mais cela est beaucoup moins sécurisé)

• Un conteneur Docker 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 systèmes réside probablement dans le fait que les systèmes fonctionnant sous docker utilisent en réalité 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é (généralement appelé un bac à sable) . Ceux-ci sont généralement basés sur le chroot, avec une supervision supplémentaire - trouvez-en un qui vous convient.

• Un simple chroot sera moins sécurisé (en particulier en ce qui concerne l'exécution de programmes), mais peut-être un peu plus vite, mais ... Vous aurez besoin de construire / copier une arborescence racine distincte et d'utiliser des montages de liaisons pour /devetc. (voir Note 1 ci-dessous!). En règle générale, cette approche ne peut donc pas être recommandée, en particulier si vous pouvez utiliser un sandboxenvironnement plus sécurisé et souvent plus facile à configurer .

Note 0: Pour l'aspect d'un "utilisateur spécial", comme lenobodycompte: Cela donne peu de sécurité, bien moins qu'un simplechroot. Unnobodyutilisateur peut toujours accéder aux fichiers et programmes dotés dedroits de lecture et d' exécution définis pour d' autres . Vous pouvez le tester avecsu -s /bin/sh -c 'some command' nobody. Et si vous avez un fichier de configuration / historique / cache accessible à n'importe qui (par une erreur ou par une faille de sécurité mineure), un programme exécuté avecnobodyles autorisations de peut y accéder, grep pour les données confidentielles (comme "pass =" etc.) et de nombreuses façons l'envoyer sur le net ou autre chose.

Note 1: Comme Gilles l’a souligné dans un commentaire ci - dessous , un environnement chroot simple offrira très peu de sécurité contre les exploits visant l’élévation des privilèges. Un seul chroot est logique du point de vue de la sécurité, que si l'environnement est minime, composé uniquement de programmes dont la sécurité est confirmée(mais le risque d'exploiter des vulnérabilités potentielles au niveau du noyau demeure), et tous les programmes non fiables exécutés dans le chroot sont en cours d'exécution en tant qu'utilisateur qui n'exécute aucun processus en dehors du chroot. Ce que chroot empêche contre (avec les restrictions mentionnées ici), c'est la pénétration directe du système sans élévation de privilèges. Cependant, comme Gilles a noté dans un autre commentaire, même ce niveau de sécurité peut être contourné, permettant ainsi à un programme de s’échapper du noyau.

Utilisez une machine virtuelle. Rien de moins ne fournit pas beaucoup de sécurité.

Il y a quelques années, j'aurais peut-être suggéré un utilisateur dédié chrooté, etc. Mais le matériel est devenu plus puissant et le logiciel de la machine virtuelle est devenu plus facile à utiliser. En outre, les attaques standard sont devenues plus sophistiquées. Il n'y a plus aucune raison de ne pas aller tout le chemin ici.

Je recommanderais l'exécution de VirtualBox. Vous pouvez configurer la machine virtuelle en quelques minutes, puis y installer une distribution Linux. La seule configuration autre que celle par défaut que je recommande est la configuration réseau: créez une interface «NAT» (pour communiquer avec le monde entier) et une interface «hôte uniquement» (afin de pouvoir facilement copier des fichiers de et vers l’hôte, et ssh dans la VM). Désactivez l'interface NAT pendant que vous exécutez les programmes de vos étudiants¹; ne l'activez que lorsque vous installez ou mettez à niveau des packages logiciels.

Dans la machine virtuelle, créez un utilisateur par élève.

¹ _{Vous pouvez limiter l’interface NAT à une liste blanche d’utilisateurs, mais c’est plus complexe que ce dont vous avez besoin dans une configuration simple et précise.}

voici une explication très complète sur la raison pour laquelle l’utilisation de Chroot est toujours une option très viable et sur la raison pour laquelle la virtualisation de systèmes d’exploitation complets ou de matériel complet est particulièrement excessive dans certains scénarios.

ce n'est rien de plus qu'un mythe lequel Chroot n'est pas un élément 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 classiques en tant que fonction de sécurité ciblée.

contrairement à la croyance populaire, toutes les situations ne nécessitent pas une virtualisation complète du système d'exploitation, ni une simulation complète du matériel. cela peut en fait signifier qu'il faut avoir plus de surface d'attaque pour essayer de couvrir. à son tour, ce qui signifie un système moins sécurisé . (prétendument pour les administrateurs système moins avertis)

les règles sont assez simples: ne mettez rien dans le chroot qui ne soit pas nécessaire. ne lancez pas de démon en tant que root. n'exécutez pas de démon comme tout utilisateur exécutant un démon en dehors du chroot.

supprimez toutes les applications non sécurisées, les fichiers binaires setuid, les liens symboliques / liens durs sans propriétaire. remontez les dossiers inutiles en utilisant nosuid, noexec et nodev. construisez la dernière version stable du démon en cours d'exécution à partir des sources. et surtout, sécurisez le système de base!

Je vais ajouter ceci, bien après la réponse officielle à la question: MAGIC: Vieillissement malveillant dans les circuits / noyaux , qui est malheureusement bloqué derrière le mur de paiement d'ACM. Le résultat de ce papier est que la très petite largeur qui reste dans les circuits utilisés aujourd'hui vieillit et finit par tomber en panne. En trouvant les instructions correctes et en les répétant encore et encore, un attaquant peut rapidement vieillir les CI.

Aucune machine virtuelle, bac à sable, conteneur ou prison chroot n’empêcherait ce type de destruction malveillante de matériel. Les auteurs du document ont trouvé de telles séquences d'instructions et du matériel expérimental sur le point d'échouer, mais ils n'ont pas donné les instructions. Il se peut donc que ce ne soit plus une menace réelle.

Sur les Unix dérivés de BSD (y compris Mac OS X), il existe une installation appelée sandbox. La page de manuel dit

DESCRIPTION
La fonction bac à sable permet aux applications de restreindre volontairement leur accès aux ressources du système d'exploitation. Ce mécanisme de sécurité est destiné à limiter les dommages potentiels au cas où une vulnérabilité serait exploitée. Il ne remplace pas les autres contrôles d'accès du système d'exploitation.

Ceci est séparé de l' chrootinstallation qui est également disponible.