Quelle est l'utilité du montage / tmp noexec?
Beaucoup de gens (y compris le Securing Debian Manual ) recommandent de monter /tmp avec le noexec,nodev,nosuid ensemble d'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 qui permet à quelqu'un d'écrire un fichier, ou une attaque d'un utilisateur avec un compte légitime mais sans autre espace accessible en écriture.
Au fil du temps, cependant, j'ai rencontré des arguments (principalement du développeur Debian/Ubuntu Colin Watson) selon lesquels noexec est une mesure inutile, pour deux raisons potentielles:
- L'utilisateur peut exécuter
/lib/ld-linux.so <binary>pour essayer d'obtenir le même effet. - L'utilisateur peut toujours exécuter des interprètes fournis par le système sur des scripts qui ne peuvent pas être exécutés directement
Compte tenu de ces arguments, le besoin potentiel de configuration supplémentaire (par exemple debconf aime un répertoire temporaire exécutable) et la perte de commodité potentielle, est-ce une mesure de sécurité utile? Quels autres trous connaissez-vous pour permettre le contournement?
Voici les arguments pour l'utilité que j'ai trouvé jusqu'à présent:
Les noyaux modernes corrigent le /lib/ld-linux.so hole, afin qu'il ne puisse pas mapper les pages exécutables d'un système de fichiers noexec.
La question des interprètes est certainement toujours une préoccupation, même si je pense que 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'élévation de privilèges qui reposaient sur la création de syscalls particuliers malformés. Sans un attaquant fournissant un binaire, il serait beaucoup plus difficile de faire des syscalls malveillants. De plus, les interprètes de script ne devraient pas être privilégiés (je sais que cela n'a parfois jamais été le cas, comme avec un Suid Perl), et auraient donc besoin de leur propre vulnérabilité pour être utile dans une attaque. Apparemment, il est possible d'utiliser Python, au moins, pour exécuter certains exploits.
De nombreux exploits "en conserve" peuvent essayer d'écrire et d'exécuter des exécutables dans /tmp, et donc noexec réduit la probabilité de tomber sur une attaque scriptée (disons 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 Suivi des bogues de Debian , définissant APT::ExtractTemplates::TempDir dans apt.conf vers un répertoire qui n'est pas noexec et accessible à root éviterait le problème de debconf.
De nombreux paquets Debian nécessitent que/tmp soit exécutable pour que le paquet s'installe. 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 juste cette erreur lors de l'installation d'un noyau mis à jour dans la branche stable juste aujourd'hui.
Il semble donc que Debian (& dérivés?) Ne soit pas prêt pour que/tmp soit monté noexec ...
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";};
Même si des solutions de contournement existent pour la plupart des mesures de sécurité supplémentaires que vous pouvez choisir de mettre en œuvre, même les mesures de sécurité les plus faciles à contourner (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 reposent sur les valeurs par défaut afin 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é.
First: Il couvre de nombreux cas d'attaques différents. Le désactiver, car il y avait quelques moyens connus (dont certains ont même été corrigés) est bizarre. Les attaquants téléchargeant du code vers/dev/shm ou/tmp sont une chose courante qu'ils font.
La défense en profondeur consiste à sécuriser les points de route les plus courants, chacun qui les arrête rend votre système plus résistant. Pas sécurisé. Mais il aura également une chance . S'ils ne peuvent pas récupérer leur charge utile secondaire, c'est une très bonne chance 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 pas être arrêté en raison d'un autre exploit facilement accessible.
Le but est de le rendre aussi difficile que possible facilement et de supprimer 99% des attaques.
Second: Il arrête les mauvaises pratiques (exécuter des trucs à partir de temp, faire des installations d'applications majeures via/tmp au lieu d'un tmpdir utilisateur), laissant les données dans/tmp. Les programmes d'installation personnalisés sont généralement comprennent 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é en permanence .
Troisième: En 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 gérons des serveurs pour de l'argent et dans un but: nous sommes responsables de ce genre de choses. "Oh, je n'ai pas verrouillé/tmp parce qu'alors j'ai besoin de quelques minutes de plus quand je mettrai à jour mon logiciel l'année prochaine". Ce ne sera sûrement pas seulement cette chose qui se situe entre le chantage et le 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 peuvent également utiliser des centaines d'espions pour empoisonner la nourriture. Nous avons donc cessé de distribuer des armes à 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 de l'argent, des durées de vie limitées et aimeraient également passer du temps avec leur famille: Ne sautez pas les trucs faciles.
Certaines applications nécessitent l'installation de/tmp pour être exécutables. Lors d'un précédent travail, avant d'y arriver, les administrateurs avaient configuré/tmp noexec, mais j'ai découvert que le package db2 ne s'installait pas. Même si vous décompressez le package 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 l'autorisation refusée. Si vous ne savez pas que le système de fichiers est monté sur noexec, cela peut être un peu trompeur. Il n'a pu continuer 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 pourrait y en avoir d'autres. Je n'ai pas trouvé de raison vraiment convaincante pour cela. Si vous voulez une meilleure sécurité, j'irais plutôt avec selinux.