Quelle est l'utilité de mount / tmp noexec?

39

De nombreuses personnes (y compris le manuel Sécuriser Debian ) recommandent un montage /tmpavec l' noexec,nodev,nosuidensemble des options. Ceci est généralement présenté comme un élément d'une stratégie de «défense en profondeur», en empêchant l'escalade d'une attaque permettant à une personne d'écrire un fichier, ou une attaque par un utilisateur avec un compte légitime mais sans autre espace inscriptible.

Au fil du temps, cependant, j'ai rencontré des arguments (principalement de Colin Watson, développeur de Debian / Ubuntu) qui noexecest une mesure inutile, pour deux raisons possibles:

  1. L'utilisateur peut exécuter /lib/ld-linux.so <binary>pour tenter d'obtenir le même effet.
  2. L'utilisateur peut toujours exécuter des interpréteurs fournis par le système sur des scripts qui ne peuvent pas être exécutés directement.

Compte tenu de ces arguments, du besoin éventuel de davantage de configuration (par exemple, debconfun répertoire temporaire exécutable), et de la perte de commodité, constitue-t-il une mesure de sécurité valable? Quels autres trous connaissez-vous qui permettent le contournement?

Phil Miller
la source
1
@neoice: J'ai entendu dire que des applications s'arrêtent parfois si / tmp n'est pas exécutable. Je n'ai pas encore vu cela arriver cependant. Regardez TuxGuitar-1.2 ... ça arrive. Ne démarrera pas si / tmp n'est pas monté sans l'option noexec, car il décompresse les bibliothèques et essaie de les charger.
Site Recovery Manager de VMware exécute les scripts de "/ tmp": IP personnalisation échoue lors d' un basculement ou test de basculement d'un plan de récupération dans vCenter Site Recovery Manager (2021083): kb.vmware.com/selfservice/microsites/...
1
Je sais que l'utilitaire de compression appelé snappy supprime un fichier .so dans / tmp et ne peut pas s'exécuter s'il est monté avec noexec. (il est utilisé par défaut dans cassandra et kafka) IMHO c'est une raison pour ne pas utiliser snappy plutôt que pour ne pas monter / tmp noexec
jorfus

Réponses:

31

Voici les arguments en faveur de l'utilité que j'ai développés jusqu'à présent:

Les noyaux modernes corrigent le /lib/ld-linux.sotrou afin qu'il ne puisse pas mapper les pages exécutables à partir d'un noexecsystème de fichiers.

Le point des interprètes est certainement toujours une préoccupation, même si je pense moins que ce que les gens pourraient prétendre. Le raisonnement que je peux en venir à dire est qu’il existe de nombreuses vulnérabilités d’escalade de privilèges reposant sur des appels système malformés particuliers. Sans un attaquant fournissant un binaire, il serait beaucoup plus difficile de faire des appels système pervers. De plus, les interprètes de script devraient être non privilégiés (je sais que cela n'a pas toujours été le cas, par exemple avec un suid perl), et il faudrait donc que leur propre vulnérabilité soit utile lors d'une attaque. Apparemment, il est possible d'utiliser Python, au moins, pour exécuter certains exploits.

De nombreux exploits "en boîte" peuvent essayer d’écrire et d’exécuter des exécutables /tmp, noexecréduisant ainsi la probabilité de tomber dans une attaque scriptée (par exemple dans la fenêtre entre la divulgation de la vulnérabilité et l’installation du correctif).

Par conséquent, il est toujours avantageux de monter /tmpavec noexec.

Comme décrit dans le suivi des bogues de Debian , la mise APT::ExtractTemplates::TempDirdans apt.confun répertoire qui n'est pas noexecet accessible à la racine éviterait le problème de debconf.

Phil Miller
la source
Cependant, j'ai entendu dire que des applications seraient parfois interrompues si / tmp n'était pas exécutable. Je n'ai pas encore vu cela arriver cependant.
Neoice
Comme indiqué dans le manuel lié à la question, cela perturbe la pré-configuration du paquet Debconf sans configurer d'alternative.
Phil Miller
2
Oui, noexec est une très bonne couche supplémentaire en matière de sécurité et je n’ai pas vu les dégâts qui en résulteraient. L'installation de paquets est la seule chose et même cela peut être corrigé comme indiqué dans les réponses fournies ici. Comme ma solution, j'ai un alias comme celui-ci: alias update = "mount -o exec, remount / tmp && apt-get update && apt-get upgrade && mount -o noexec, remount / tmp"
Janne Pikkarainen
1
Je suppose que cela est rare, mais des packages écrits pour exécuter quelque chose à partir de / tmp en dehors du contexte d’installation de package existent (par exemple, la version actuelle du middleware pour l’utilisation des cartes d’identité électroniques belges).
equaeghe
equaeghe: De quel paquet s'agit-il? Cela devrait probablement être signalé comme un bug. Je suis prêt à parier qu'il existe également une faille de sécurité dans la façon dont elle utilise cela.
Phil Miller
7

De nombreux paquets Debian exigent que / tmp soit exécutable pour pouvoir installer le paquet. Ceux-ci sont souvent marqués comme des bugs (de gravité 'normale' / 'wishlist'):

https://www.google.com/#q=site:bugs.debian.org+noexec+/tmp

Je viens de recevoir cette erreur lors de l'installation d'un noyau mis à jour sur la branche stable, aujourd'hui.

Il semble donc que Debian (& dérivés?) N’est pas prêt pour que / tmp soit monté noexec ...

thomasrutter
la source
6

ajoutez ce qui suit dans /etc/apt.conf ou /etc/apt/apt.conf.d/50remount

DPkg::Pre-Install-Pkgs {"mount -o remount,exec /tmp";};
DPkg::Post-Invoke {"mount -o remount /tmp";};
Karmawhore
la source
6
J'ai remplacé mountpar /bin/mountau cas où PATH serait modifié. Tu ne sauras jamais.
Lekensteyn
4

Même s'il existe des solutions de contournement pour la plupart des mesures de sécurité supplémentaires que vous pouvez choisir d'implémenter, même les mesures de sécurité les plus facilement contournées (telles que le montage / tmp noexec ou l'exécution de SSH sur un autre port) contrecarreront les attaques automatisées ou scriptées qui s'appuient sur les valeurs par défaut dans l'ordre. Pour fonctionner. Cela ne vous protégera pas contre un attaquant déterminé et averti, mais bien plus de 99% du temps, vous ne serez pas contre un attaquant déterminé ou averti. Au lieu de cela, vous vous défendrez contre un script d'attaque automatisé.

tylerl
la source
2

Premièrement: il couvre de nombreux cas d’attaque différents. Le désactiver parce qu’il existait quelques méthodes connues (parfois même fixes) est étrange. Les pirates téléchargent du code dans / dev / shm ou / tmp est une chose courante.

La défense en profondeur consiste à sécuriser les points de cheminement les plus courants, chaque arrêt les rendant plus sûr pour votre système. Pas sécurisé. Mais ça va aussi avoir une chance . S'ils ne peuvent pas récupérer leur charge utile secondaire, c'est une chance très bonne que vous obtenez.

  • Il peut également être arrêté par les restrictions utilisateur iptables.
  • Il pourrait également être arrêté par SELinux.
  • Il pourrait également ne pas être arrêté en raison d'un autre exploit facilement accessible.

Le point est de le rendre aussi dur que vous facilement pouvez, et découpez 99% des attaques.

Deuxièmement, cela met fin aux mauvaises pratiques (exécuter des tâches à partir de temp, effectuer des installations d’application majeures via / tmp au lieu d’un utilisateur tmpdir), en laissant les données dans / tmp. Les installateurs personnalisés comprennent généralement TMPDIR De plus, même si ce n’est pas le cas: le temps d’installation, en tant qu’action ponctuelle, n’est pas une raison valable pour désactiver un problème de sécurité de manière permanente .

Troisièmement: Considérant les espaces de noms anonymes dans / tmp (une "fonctionnalité"), vous voulez vraiment restreindre ce qui y est mis et courir à partir de là.

Forth: La commodité n’est pas un facteur pertinent à cet égard. En supposant que nous exploitons des serveurs pour de l'argent et dans un but précis: nous en sommes responsables. "Oh, je n'ai pas verrouillé / tmp parce que j'ai besoin de quelques minutes de plus pour mettre à jour mon logiciel l'année prochaine". Ce ne sera sûrement pas la seule chose qui se situe entre le chantage et le simple fait d’être bien. Une bonne raison? Je ne pense pas.

Celui-ci, ça va:

"Nous avons appris que les ennemis peuvent attaquer sans préavis. Ils pourraient également utiliser des centaines d'espions pour empoisonner la nourriture. Nous avons donc cessé de distribuer des armes à feu à nos soldats."

Attends quoi?

Il existe d'autres mesures qui nécessitent beaucoup plus d'efforts, d'expérience et de chance pour sécuriser un système, et sachant que les gens ont peu d'argent, une durée de vie limitée et qu'ils aimeraient aussi passer du temps avec leur famille: Ne sautez pas les tâches faciles.

Florian Heigl
la source
1

Il existe des applications qui nécessitent que / tmp soit exécutable pour être installé. Lors d'un travail précédent, avant mon arrivée, les administrateurs avaient configuré / tmp noexec, mais j'ai découvert que le paquet db2 ne s'installait pas. Même si vous désarchivez le paquet db2 ailleurs, la procédure d'installation copie certains fichiers dans / tmp et s'attend à pouvoir l'exécuter, ce qui a bien sûr échoué avec une autorisation refusée. Si vous ne savez pas que le système de fichiers est monté noexec, cela peut être un peu trompeur. Il n'a été possible de poursuivre l'installation qu'après avoir remonté / tmp sans noexec.

Quoi qu'il en soit, le fait est qu'au moins un produit commercial nécessite que / tmp ne soit pas monté noexec, et il peut y en avoir d'autres. Je n'ai pas trouvé de raison vraiment convaincante pour cela. Si vous voulez une meilleure sécurité, je choisirais plutôt selinux.

LSD
la source
Une analyse d'un exploit pour la vulnérabilité Samba, qui serait stoppée par un noexec / tmp: bobao.360.cn/learning/detail/4168.html (Google Translate était recommandé dans Google Translate. Cela romprait l'exploit initial, ainsi qu'un grande partie de la charge utile ...) (Vous pouvez casser de nombreux exploits automatiques courants de cette façon ....). mount -o remount,exec /tmpfonctionne lorsque vous devez installer des éléments ... (oui, il est trivial de contourner le problème, mais de nombreux attaquants ne semblent pas déranger ...)
Gert van den Berg