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

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?

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.

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 ...

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";};

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é.

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.

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.