Donc tu parles d'un cas ou il n'y a pas un buffer overflow (ou autre détournement bas niveau), donc je ne peux pas avoir de l’exécution de code complète dans l'espace mémoire du programme, mais je peux avoir un exec/system arbitraire sur un programme qui existe déjà sur le disque ?
Par exemple, le programme passe des variables mal échappées venant de dehors.
Si c'est le cas, ça veut dire qu'il y a déjà un appel à exec/system. Et si tu as un exec/system dans le programme principal, tu as une dépendance vers un autre binaire, donc il faut la gérer.
Suivant le type de binaire, le raisonnement n'est pas le même. Si c'est 2 binaires statiques qui s'appellent, oui, tu peux en effet réussir à éviter d'avoir un gestionnaire de paquet dans le conteneur final. Mais je pense que c'est assez rare, et la question se pose de pourquoi ne pas mettre tout dans 1 seul binaire, ou dans 2 conteneurs séparés.
Si un des 2 programmes est fourni ailleurs ou n'est pas statique, par exemple via ta distro (exemple, tu lances imageMagick), alors tu va sans doute hériter d'un gestionnaire de paquet dans le conteneur pour installer le binaire et ses éventuels dépendances, et tu peux pas utiliser "FROM scratch" + "COPY from" facilement.
Mais du coup, si tu as dnf/apt/pip dans le conteneur et une faille qui permet d’exécuter un programme arbitraire mais qui doit exister, il suffit d'installer un paquet vérolé pour exécuter du code (en l'absence d'autre mesures de protection).
Par exemple, "pip install --user monpaquetpasverolé".
Et si tu utilises system (en tout cas en python), il y a des chances que ça tire aussi un shell pour son fonctionnement que tu ne peux pas retirer, ce qui donne plein de primitives funs (cat/echo, etc).
Il y a des outils qui permettent d'assembler des conteneurs sans avoir de gestionnaire de paquets à l'intérieur (e.g. apko, si je comprends bien), mais ça reviens à changer un peu tout le fonctionnement (et sans doute de distro).
Et n'oublions pas aussi que si tu as python/ruby/perl/node dans le conteneur pour lancer le programme ruby/perl/python/node, tu as aussi defacto de quoi lancer des onliners, donc je pense qu'un ménage visant à retirer les dépendances ne va pas aider pour la sécurité si tu as un interpréteur que tu peux pas retirer.
[^] # Re: FROM scratch
Posté par Misc (site web personnel) . En réponse au journal Comment sécurisez-vous les images docker externes ?. Évalué à 3. Dernière modification le 06 novembre 2022 à 12:31.
Donc tu parles d'un cas ou il n'y a pas un buffer overflow (ou autre détournement bas niveau), donc je ne peux pas avoir de l’exécution de code complète dans l'espace mémoire du programme, mais je peux avoir un exec/system arbitraire sur un programme qui existe déjà sur le disque ?
Par exemple, le programme passe des variables mal échappées venant de dehors.
Si c'est le cas, ça veut dire qu'il y a déjà un appel à exec/system. Et si tu as un exec/system dans le programme principal, tu as une dépendance vers un autre binaire, donc il faut la gérer.
Suivant le type de binaire, le raisonnement n'est pas le même. Si c'est 2 binaires statiques qui s'appellent, oui, tu peux en effet réussir à éviter d'avoir un gestionnaire de paquet dans le conteneur final. Mais je pense que c'est assez rare, et la question se pose de pourquoi ne pas mettre tout dans 1 seul binaire, ou dans 2 conteneurs séparés.
Si un des 2 programmes est fourni ailleurs ou n'est pas statique, par exemple via ta distro (exemple, tu lances imageMagick), alors tu va sans doute hériter d'un gestionnaire de paquet dans le conteneur pour installer le binaire et ses éventuels dépendances, et tu peux pas utiliser "FROM scratch" + "COPY from" facilement.
Mais du coup, si tu as dnf/apt/pip dans le conteneur et une faille qui permet d’exécuter un programme arbitraire mais qui doit exister, il suffit d'installer un paquet vérolé pour exécuter du code (en l'absence d'autre mesures de protection).
Par exemple, "pip install --user monpaquetpasverolé".
Et si tu utilises system (en tout cas en python), il y a des chances que ça tire aussi un shell pour son fonctionnement que tu ne peux pas retirer, ce qui donne plein de primitives funs (cat/echo, etc).
Il y a des outils qui permettent d'assembler des conteneurs sans avoir de gestionnaire de paquets à l'intérieur (e.g. apko, si je comprends bien), mais ça reviens à changer un peu tout le fonctionnement (et sans doute de distro).
Et n'oublions pas aussi que si tu as python/ruby/perl/node dans le conteneur pour lancer le programme ruby/perl/python/node, tu as aussi defacto de quoi lancer des onliners, donc je pense qu'un ménage visant à retirer les dépendances ne va pas aider pour la sécurité si tu as un interpréteur que tu peux pas retirer.