Docker: quand utiliser apparmor vs seccomp vs --cap-drop
Docker semble prendre en charge à la fois apparmor et seccomp. Docker permet également de supprimer des capacités lors de l'exécution d'un conteneur.
Cependant, je n'ai trouvé aucune documentation ni aucune directive sur le moment d'utiliser l'approche.
Il semble y avoir un chevauchement important dans leur utilisation, je n'ai pas pu trouver de ligne directrice générale sur le moment d'utiliser laquelle de ces options.
Quelqu'un peut-il fournir des directives?
Dans mon cas, je dois exécuter beaucoup de code d'étudiants sur le serveur. Je veux leur permettre d'exécuter Java et les programmes c ++. Autoriser l'accès en écriture à un répertoire (volume de données). Ils n'ont pas besoin d'un accès réseau, ou quoi que ce soit de compliqué.
Veuillez fournir des directives sur la façon de sécuriser.
Vous pouvez tous les utiliser.
Chacune de ces fonctionnalités de sécurité a des objectifs différents et il y a en fait peu de chevauchement. Ils fonctionnent tous pour réduire les dommages qu'un processus peut causer une fois qu'il a été compromis. Ils sont tous très peu coûteux et peuvent être utilisés pour améliorer considérablement la sécurité des logiciels.
Seccomp est une fonctionnalité Linux qui permet à un programme de l'espace utilisateur de configurer des filtres d'appel système. Ces filtres spécifient quels appels système sont autorisés et quels arguments ils peuvent avoir. Il s'agit d'un filtre de très bas niveau qui réduit la surface d'attaque du noyau. Par exemple, un bogue dans keyctl() qui permet à de simples appels à ce syscall d'élever des privilèges ne serait pas nécessairement utilisable pour privesc dans un programme qui a restreint l'accès à cet appel.
AppArmor est un framework de contrôle d'accès obligatoire qui fonctionne comme un LSM (Linux Security Module). Il est utilisé pour mettre en liste blanche ou mettre sur liste noire l'accès d'un sujet (programme) à un objet (fichier, chemin, etc.). AppArmor peut être utilisé pour permettre à un programme d'avoir un accès en lecture à /etc/passwd, mais non /etc/shadow. Les stratégies peuvent également être utilisées pour restreindre les capacités, voire limiter l'accès au réseau.
Capacités et la suppression de capacité est une technique générale par laquelle un processus privilégié révoque un sous-ensemble des privilèges dont il est doté. Un processus racine peut supprimer, par exemple, les capacités requises pour créer des connexions brutes au réseau, ou les capacités requises pour contourner les autorisations de fichier UNIX standard (DAC), même s'il reste racine. Cette technique n'est pas très fine car il n'y a qu'un nombre limité de capacités qui peuvent être abandonnées, mais elle réduit les dommages qu'un programme peut faire s'il est néanmoins compromis.
En général, vous devez savoir que:
Seccomp réduit les chances qu'une vulnérabilité du noyau soit exploitée avec succès.
AppArmor empêche une application d'accéder aux fichiers auxquels elle ne devrait pas accéder.
La suppression des capacités réduit les dommages qu'un processus privilégié compromis peut faire.
Voir aussi Comment le Sandboxing est-il implémenté?
Bien répondu par @ forest , mais j'aimerais ajouter quelques suggestions qui reflètent mon point de vue sur les cadres de sécurité et la conception de la sécurité en général. L'application de la sécurité va de pair avec la connaissance de ce contre quoi vous vous protégez, ou du moins de ce que vous protégez. Mais tout cela doit commencer par une politique de sécurité. Une fois la politique formulée, le choix est plus facile à faire. Examinons quelques cas, qui peuvent ou non refléter vos cas d'utilisation. Mais avant de les considérer, il peut être utile de restreindre les options disponibles aux éléments suivants:
- Si vous ne pouvez pas modifier le programme cible , les seules options dont vous disposez sont MAC - Contrôle d'accès obligatoire au mieux), car tout ce dont vous avez besoin est fournir une politique de sécurité par laquelle un programme donné sera évalué. Peu importe le programme, peu importe le langage d'implémentation, car les couches de sécurité du système d'exploitation s'en chargent. Les bacs à sable sont une autre option, mais ils entrent dans la catégorie 3.
- Si vous [ré] écrivez (ou pouvez modifier) votre programme : bonne chance alors, car vous pouvez réellement écrire un programme sensible à la sécurité en appelant certaines primitives de sécurité fournies par un framework de votre choix [plus bas]. Cependant, vous pouvez être limité dans la mesure où le cadre que vous choisissez n'a pas de liaisons dans votre langage de programmation, car la plupart d'entre elles ont tendance à être de bas niveau. Est-ce C, Java, Go ou Javascript (ouais, comme si!)? Vous pouvez être seul dans la plupart des cas, alors, bienvenue au club. Mais il y a des options. Et parfois stupides.
- Vous ne vous souciez pas et vous voulez juste empêcher les choses d'exploser dans votre visage (c'est-à-dire qu'aucune des réponses ci-dessus ne vaut votre temps): bacs à sable alors? Peut-être quelque chose d'aussi dramatique qu'une machine virtuelle, ou si vous êtes d'humeur pour l'inconnu, les conteneurs d'application sont vos meilleurs amis. Cependant, les esprits les plus avertis de la sécurité avertissent que --- (les conteneurs ne contiennent pas . Mais vous bénéficiez toujours au moins d'une certaine isolation des ressources sans avoir à connaître les internes de vos programmes. Conteneurs non privilégiés sont fortement recommandés. Mais sinon, les VM sont toujours cool.
Et maintenant, les cas:
- Je veux exécuter un programme d'une manière qui est à l'abri d'une exploitation malveillante: puisque cela signifie toute attaque , connue ou inconnu, rien n'est garanti pour satisfaire votre exigence (chaque cadre de sécurité devrait vous le dire). Mais au moins, restreindre votre programme au moins d'appels système possibles réduit sa surface d'attaque, bien que vous puissiez toujours être attaqué de n'importe où, même si cela représente 1% des moyens possibles. Cependant, si la suppression des privilèges des applications pour les rendre moins utiles à l'attaquant, le filtrage des appels système et les systèmes de capacités seront utiles. Seccomp (disponible sur Linux), Capsicum (disponible sur FreeBSD, et bientôt sur Linux), et capacités POSIX sont des options ici.
- Je veux restreindre mes programmes au comportement connu/attendu: facile (pour les programmes simples) - si vous pouvez définir le comportement d'exécution en termes de fichiers accédés ou d'objets du noyau, alors Les frameworks [~ # ~] mac [~ # ~] peuvent vous aider (AppArmor, SELinux, ...). Cependant, vous devrez également faire des choix quant au niveau d'abstraction que vous souhaitez exprimer vos politiques, de sorte que la précision et la flexibilité vous entraîneront dans différentes directions (les chemins sont-ils suffisamment précis, les inodes sont-ils gérables pour vous, qu'en est-il des segments de mémoire? ).
- J'ai souvent besoin d'exécuter des programmes avec des privilèges élevés et je crains que cela ne soit trop risqué: nous y sommes tous allés. La suppression des capacités est probablement l'option la plus raisonnable. Il est spécifique au système d'exploitation (et à tous les autres), mais au moins indépendant de l'implémentation s'il est effectué dans le cadre du contrôle d'accès sur une machine donnée (par opposition à l'invocation de l'interface de capacités par programme, qui dépendra des liaisons disponibles dans votre langue ).