Des questions plus similaires avec plus de réponses méritent l'attention:
REMARQUE: certaines des réponses indiquent des solutions spécifiques non encore mentionnées ici.
En fait, il existe de nombreux outils d'emprisonnement avec une implémentation différente, mais beaucoup d'entre eux ne sont pas sécurisés par conception (comme fakeroot, LD_PRELOADbasés sur), ou incomplets (comme fakeroot-ng, ptracebasés sur), ou nécessiteraient root ( chroot, ou plashmentionnés à fakechroot étiquette d'avertissement ).
Ce ne sont que des exemples; J'ai pensé à les répertorier tous côte à côte, avec une indication de ces 2 fonctionnalités ("peut être approuvé?", "Nécessite la configuration de root?"), Peut-être dans les implémentations de virtualisation au niveau du système d'exploitation .
En général, les réponses y couvrent l'ensemble des possibilités décrites et encore plus:
machines virtuelles / OS
extension du noyau (comme SELinux)
- (mentionné dans les commentaires ici),
chroot
Assistants basés sur Chroot (qui doivent cependant être setUID root, car chrootnécessite root; ou peut-être chrootpourrait fonctionner dans un espace de noms isolé - voir ci-dessous):
[pour en dire un peu plus à leur sujet!]
Outils d'isolement basés sur chroot connus:
- hasher avec ses commandes
hsh-runet hsh-shell. ( Hasher a été conçu pour créer des logiciels de manière sûre et reproductible.)
- schroot mentionné dans une autre réponse
- ...
ptrace
Une autre solution d'isolement fiable (en plus d' uneseccomp solution basée sur ) serait l'interception complète de syscall ptrace, comme expliqué dans la page de manuel pour fakeroot-ng:
Contrairement aux implémentations précédentes, fakeroot-ng utilise une technologie qui ne laisse au processus tracé aucun choix quant à l'utilisation ou non des "services" de fakeroot-ng. Compiler un programme de manière statique, appeler directement le noyau et manipuler son propre espace d'adressage sont toutes des techniques qui peuvent être trivialement utilisées pour contourner le contrôle basé sur LD_PRELOAD sur un processus, et ne s'appliquent pas à fakeroot-ng. Il est théoriquement possible de façonner le fakeroot-ng de manière à avoir un contrôle total sur le processus tracé.
Bien que cela soit théoriquement possible, cela n'a pas été fait. Fakeroot-ng suppose certaines hypothèses "bien comportées" sur le processus en cours de traçage, et un processus qui casse ces hypothèses peut, sinon totalement échapper, au moins contourner une partie du "faux" environnement qui lui est imposé par fakeroot- ng. En tant que tel, vous êtes fortement déconseillé d'utiliser fakeroot-ng comme outil de sécurité. Les rapports de bogues qui prétendent qu'un processus peut délibérément (par opposition à par inadvertance) échapper au contrôle de faux-root-ng seront soit fermés comme "pas un bogue", soit marqués comme de faible priorité.
Il est possible que cette politique soit repensée à l'avenir. Pour l'instant, cependant, vous avez été prévenu.
Pourtant, comme vous pouvez le lire, fakeroot-nglui-même n'est pas conçu à cet effet.
(BTW, je me demande pourquoi ils ont choisi d'utiliser l' seccompapproche basée sur le chrome plutôt qu'une approche basée ptracesur ...)
Parmi les outils non mentionnés ci-dessus, j'ai noté Geordi pour moi-même, car j'ai aimé que le programme de contrôle soit écrit en Haskell.
Outils d'isolation basés sur ptrace connus:
seccomp
Une méthode connue pour réaliser l'isolement consiste à utiliser l'approche sandboxing seccomp utilisée dans Google Chromium . Mais cette approche suppose que vous écriviez un assistant qui traiterait certains (ceux autorisés) de l'accès aux fichiers "interceptés" et d'autres appels système; et aussi, bien sûr, faire des efforts pour "intercepter" les appels système et les rediriger vers l'assistant (peut-être, cela signifierait même une chose telle que remplacer les appels système interceptés dans le code du processus contrôlé; donc, cela ne sonne pas pour être assez simple; si vous êtes intéressé, vous feriez mieux de lire les détails plutôt que juste ma réponse).
Plus d'informations connexes (à partir de Wikipedia):
(Le dernier élément semble être intéressant si l'on recherche une seccompsolution générale en dehors de Chromium. Il y a aussi un article de blog qui mérite d'être lu par l'auteur de "seccomp-nurse": SECCOMP comme solution de sandboxing?. )
L'illustration de cette approche du projet "seccomp-nurse" :
Un seccomp "flexible" possible dans le futur de Linux?
En 2009, il y avait également des suggestions pour patcher le noyau Linux afin qu'il y ait plus de flexibilité dans le seccompmode - afin que "beaucoup d'acrobaties dont nous avons actuellement besoin puissent être évitées". ("Acrobatics" fait référence aux complications de l'écriture d'un assistant qui doit exécuter de nombreux appels système potentiellement innocents au nom du processus emprisonné et de la substitution des appels système potentiellement innocents dans le processus emprisonné.) Un article de LWN a écrit à ce sujet:
Une suggestion qui a émergé était d'ajouter un nouveau "mode" à seccomp. L'API a été conçue avec l'idée que différentes applications peuvent avoir des exigences de sécurité différentes; il inclut une valeur "mode" qui spécifie les restrictions à mettre en place. Seul le mode original a été implémenté, mais d'autres peuvent certainement être ajoutés. La création d'un nouveau mode qui permettait au processus de lancement de spécifier quels appels système seraient autorisés rendrait l'installation plus utile pour des situations comme le bac à sable Chrome.
Adam Langley (également de Google) a publié un patch qui fait exactement cela. La nouvelle implémentation "mode 2" accepte un masque de bits décrivant les appels système accessibles. Si l'un d'eux est prctl (), alors le code en bac à sable peut restreindre davantage ses propres appels système (mais il ne peut pas restaurer l'accès aux appels système qui ont été refusés). Tout compte fait, cela ressemble à une solution raisonnable qui pourrait faciliter la vie des développeurs de sandbox.
Cela dit, ce code ne peut jamais être fusionné car la discussion est depuis passée à d'autres possibilités.
Cette «seccomp flexible» rapprocherait les possibilités de Linux de fournir la fonctionnalité souhaitée dans le système d'exploitation, sans avoir besoin d'écrire des aides aussi compliquées.
(Un article de blog avec essentiellement le même contenu que cette réponse: http://geofft.mit.edu/blog/sipb/33 .)
espaces de noms ( unshare)
L'isolement via des espaces de noms ( unsharesolutions basées sur ) - non mentionné ici - par exemple, le non-partage des points de montage (combinés avec FUSE?) Pourrait peut-être faire partie d'une solution de travail pour vous qui souhaitez limiter les accès au système de fichiers de vos processus non fiables.
Plus d'informations sur les espaces de noms, maintenant que leur implémentation est terminée (cette technique d'isolation est également connue sous le nme "Linux Containers", ou "LXC" , n'est-ce pas? ..):
"L'un des objectifs généraux des espaces de noms est de soutenir la mise en œuvre de conteneurs, un outil de virtualisation légère (ainsi que d'autres objectifs)" .
Il est même possible de créer un nouvel espace de noms d'utilisateurs, de sorte qu'un "processus puisse avoir un ID utilisateur normal non privilégié en dehors d'un espace de noms d'utilisateurs tout en ayant un ID utilisateur de 0 à l'intérieur de l'espace de noms. Cela signifie que le processus dispose de privilèges root complets pour les opérations à l'intérieur de l'espace de noms utilisateur, mais n'est pas privilégié pour les opérations à l'extérieur de l'espace de noms ".
Pour de vraies commandes de travail, procédez comme suit:
et programmation / compilation spéciale en espace utilisateur
Mais bien sûr, les garanties de "prison" souhaitées peuvent être mises en œuvre en programmant dans l'espace utilisateur ( sans prise en charge supplémentaire de cette fonctionnalité par le système d'exploitation ; c'est peut-être pourquoi cette fonctionnalité n'a pas été incluse en premier lieu dans la conception des systèmes d'exploitation ); avec plus ou moins de complications.
Le dessus ptrace- ou seccompsandbox à base peut être considérée comme certaines variantes de mise en œuvre des garanties en écrivant une aide sandbox qui contrôle vos autres processus, qui seraient considérés comme des « boîtes noires », arbitraire programmes Unix.
Une autre approche pourrait être d'utiliser des techniques de programmation qui peuvent se soucier des effets qui doivent être interdits. (Ce doit être vous qui écrivez les programmes alors; ce ne sont plus des boîtes noires.) Pour en mentionner un, utiliser un langage de programmation pur (qui vous obligerait à programmer sans effets secondaires) comme Haskell fera simplement tous les effets du programme explicite, de sorte que le programmeur peut facilement s'assurer qu'il n'y aura pas d'effets interdits.
Je suppose qu'il existe des installations de sandbox disponibles pour ces programmes dans un autre langage, par exemple Java.
Certaines pages accumulant des informations sur ce sujet ont également été pointées dans les réponses: