Solution 1 :
Voici les arguments en faveur de l'utilité que j'ai trouvés jusqu'à présent :
Les noyaux modernes corrigent le /lib/ld-linux.so trou, de sorte qu'il ne pourra pas mapper des pages exécutables à partir d'un noexec système de fichiers.
Le point sur les interprètes est certainement toujours une préoccupation, bien que je pense qu'il y en ait moins que ce que les gens pourraient prétendre. Le raisonnement que je peux trouver est qu'il y a eu de nombreuses vulnérabilités d'escalade de privilèges qui reposaient 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 malveillants. De plus, les interpréteurs de scripts ne devraient pas être privilégiés (je sais que cela n'a parfois pas été le cas, comme avec un suid perl), et auraient donc besoin de leur propre vulnérabilité pour être utiles dans une attaque. Apparemment, il est possible d'utiliser Python, au moins, pour exécuter certains exploits.
De nombreux exploits "préparés" peuvent essayer d'écrire et d'exécuter des exécutables en /tmp , et donc noexec réduit 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).
Ainsi, il y a toujours un avantage de sécurité à monter /tmp avec noexec .
Comme décrit dans le gestionnaire de bogues de Debian, le réglage APT::ExtractTemplates::TempDir en apt.conf dans un répertoire qui n'est pas noexec et accessible à root éviterait le souci de debconf.
Solution 2 :
De nombreux packages Debian nécessitent que /tmp soit exécutable pour que le package puisse être installé. Ceux-ci sont souvent marqués comme des bogues (de gravité "normale"/"liste de souhaits") :
https://www.google.com/#q=site:bugs.debian.org+noexec+/tmp
J'ai reçu cette erreur lors de l'installation d'un noyau mis à jour sur la branche stable juste aujourd'hui.
Il semble donc que Debian (et ses dérivés ?) ne soit pas prêt pour que /tmp soit monté noexec...
Solution 3 :
ajoutez ce qui suit à /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";};
Solution 4 :
Même s'il existe des solutions de contournement pour la plupart des mesures de sécurité supplémentaires que vous pourriez choisir de mettre en œuvre, même les mesures de sécurité les plus faciles à contourner (telles que le montage de /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 bien informé, mais bien plus de 99 % du temps, vous ne serez pas confronté à un attaquant déterminé ou bien informé. Au lieu de cela, vous vous défendrez contre un script d'attaque automatisé.
Solution 5 :
Première : Il couvre de nombreux cas d'attaque différents. Le désactiver parce qu'il y avait quelques façons connues de le contourner (dont certains sont même fixes) est bizarre. Attaquants téléchargeant du code vers /dev/shm ou /tmp est une chose courante qu'ils font.
La défense en profondeur consiste à sécuriser les waypoints les plus courants, chacun qui les arrête rend votre système plus résistant. Pas sécurisé. Mais il aura aussi une chance . S'ils ne peuvent pas récupérer leur charge utile secondaire, il y a de fortes chances que vous en obteniez.
- Il peut également être arrêté par les restrictions d'utilisation d'iptables.
- Il peut également être arrêté par SELinux.
- Cela pourrait aussi pas être arrêté en raison d'un autre exploit facilement accessible.
Le but est de le rendre aussi difficile que vous facilement peut, et couper 99 % des attaques.
Deuxième : Cela arrête les mauvaises pratiques (exécuter des trucs à partir de temp, faire des installations d'applications majeures via /tmp au lieu d'un utilisateur tmpdir), laissant les données dans /tmp .Les installateurs personnalisés comprennent généralement TMPDIR Aussi :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 façon permanente .
Troisième : Prise en compte des espaces de noms anonymes dans /tmp (une "fonctionnalité"), vous voulez vraiment restreindre ce qui y est mis et exécuter à partir de là.
Quatrième : La commodité n'est pas un facteur pertinent à cet égard. En supposant que nous gérons des serveurs pour de l'argent et dans un but :nous sommes responsables de tout cela. "Oh, je n'ai pas verrouillé /tmp parce qu'alors j'ai besoin de quelques minutes de plus lorsque je mettrai à jour mon logiciel l'année prochaine". Ce ne sera sûrement pas seulement cette chose qui se dresse entre le chantage et le fait d'être bien. Une bonne raison ? Je ne pense pas.
Que diriez-vous de celui-ci :
"Nous avons appris que les ennemis pouvaient attaquer sans préavis. Ils pouvaient également utiliser des centaines d'espions pour empoisonner la nourriture. Nous avons donc cessé de donner des armes à nos soldats."
Attendez, 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 un budget et une durée de vie limités et aimeraient également passer du temps avec leur famille :Ne sautez pas les choses faciles.