Frage Wie nützlich ist das Mounten von / tmp noexec?


Viele Leute (einschließlich der Das Debian-Handbuch sichern) empfehlen die Montage /tmp mit dem noexec,nodev,nosuid Reihe von Optionen. Dies wird im Allgemeinen als ein Element einer "Defense-in-Depth" -Strategie dargestellt, indem die Eskalation eines Angriffs verhindert wird, bei dem jemand eine Datei schreiben kann, oder ein Angriff eines Benutzers mit einem legitimen Account, aber keinem anderen beschreibbaren Speicherplatz.

Im Laufe der Zeit stieß ich jedoch auf Argumente (am bekanntesten von Debian / Ubuntu Developer Colin Watson) noexec ist eine nutzlose Maßnahme, für ein paar mögliche Gründe:

  1. Der Benutzer kann ausführen /lib/ld-linux.so <binary> in einem Versuch, den gleichen Effekt zu erzielen.
  2. Der Benutzer kann weiterhin vom System bereitgestellte Interpreter für Skripts ausführen, die nicht direkt ausgeführt werden können

Angesichts dieser Argumente besteht die potentielle Notwendigkeit für mehr Konfiguration (z. debconf mag ein ausführbares temporäres Verzeichnis) und der potentielle Komfortverlust ist dies eine lohnende Sicherheitsmaßnahme? Welche anderen Löcher kennen Sie, die Umgehung ermöglichen?


37
2017-10-07 23:43


Ursprung


@neoice: Ich habe gehört, dass Anwendungen gelegentlich brechen, wenn / tmp nicht ausführbar ist. Ich muss es aber tatsächlich sehen. Schau dir TuxGuitar-1.2 an ... es passiert. Wird nicht gestartet, wenn / tmp ohne noexec-Option nicht gemountet wurde, da es dort Bibliotheken entpackt und dann versucht, sie zu laden.
VMware Site Recovery Manager führt Skripts von "/ tmp" aus: Die IP-Anpassung schlägt während eines Failover- oder Test-Failovers eines Wiederherstellungsplans in vCenter Site Recovery Manager (2021083) fehl: kb.vmware.com/selfservice/microsites/...
Ich weiß, dass das Komprimierungsprogramm namens snappy eine .so-Datei in / tmp ablegt und nicht ausgeführt werden kann, wenn es noexec gemountet ist. (es ist standardmäßig in Cassandra und Kafka verwendet) IMHO ist dies ein Grund, nicht bissig zu verwenden, anstatt einen Grund, nicht zu mounten / tmp noexec - jorfus


Antworten:


Hier sind die Argumente für den Nutzen, die ich bisher gefunden habe:

Moderne Kernel fixieren die /lib/ld-linux.so loch, so dass es nicht in der Lage ist, ausführbare Seiten von a abzubilden noexec Dateisystem.

Der Dolmetscherpunkt ist sicherlich immer noch ein Problem, obwohl ich weniger von einem denke, als die Leute behaupten könnten. Die Schlussfolgerung, die ich daraus ziehen kann, ist, dass es zahlreiche Sicherheitslücken bei der Privilegien-Eskalation gegeben hat, die sich auf bestimmte fehlerhafte Syscalls stützten. Ohne einen Angreifer, der eine Binärdatei bereitstellt, wäre es viel schwieriger, böse Systemaufrufe zu machen. Außerdem sollten Skriptdolmetscher unprivilegiert sein (ich weiß, dass dies in der Vergangenheit manchmal nicht der Fall war, wie zum Beispiel mit einem suid perl), und daher würde ihre eigene Schwachstelle für einen Angriff nützlich sein. Anscheinend, es ist möglich um zumindest einige Exploits auszuführen.

Viele "vorgefertigte" Exploits können versuchen, ausführbare Dateien zu schreiben und auszuführen /tmp, und so noexec reduziert die Wahrscheinlichkeit, zu einem skriptgesteuerten Angriff zu kommen (etwa im Fenster zwischen der Offenlegung von Sicherheitslücken und der Patch-Installation).

Somit besteht immer noch ein Sicherheitsvorteil für die Montage /tmp mit noexec.

Wie beschrieben in Debians Bug TrackerEinstellung APT::ExtractTemplates::TempDir im apt.conf zu einem Verzeichnis, das nicht ist noexec und zugänglich für root würde die Debconf Sorge vermeiden.


28
2017-10-07 23:46



Wie auch immer, ich haben habe gehört, dass Anwendungen gelegentlich brechen, wenn / tmp nicht ausführbar ist. Ich muss es aber tatsächlich sehen. - neoice
Wie in dem Handbuch erwähnt, das in der Frage verlinkt ist, macht es sich mit der Vorkonfiguration des Debconf-Pakets Mühe, ohne eine Alternative einzurichten. - Phil Miller
Ja, noexec ist eine sehr gute zusätzliche Sicherheitsschicht und ich habe noch nicht gesehen, dass es bremsen würde. Paketinstallation ist das einzige Ding und sogar das kann herum bearbeitet werden, wie durch Antworten hier gesagt wird. Als meine Lösung habe ich einen Alias ​​wie folgt: alias update = "mount -o exec, remount / tmp && apt-get-update && apt-get upgrade && mount -o noexec, remount / tmp" - Janne Pikkarainen
Ich denke, es ist ungewöhnlich, aber es gibt Pakete, die geschrieben werden, um etwas von / tmp außerhalb eines Paketinstallationskontexts auszuführen (z. B. die aktuelle Version der Middleware zur Verwendung der belgischen elektronischen Ausweise). - equaeghe
Equaeghe: Welches Paket ist das? Es sollte wahrscheinlich als Fehler gemeldet werden. Ich wette, dass es eine Sicherheitslücke gibt, die auch darin zu finden ist. - Phil Miller


Viele Debian-Pakete verlangen, dass / tmp ausführbar sein muss, damit das Paket installiert werden kann. Diese werden oft als Bugs (von 'normal' / 'Wunschliste' Schweregrad) markiert:

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

Ich habe gerade diesen Fehler erhalten, als ich gerade einen aktualisierten Kernel in den Stable-Zweig installiert habe.

Es sieht also so aus, als wäre Debian (& derivatives?) Nicht bereit für / tmp, um noexec gemountet zu werden ...


7
2017-08-21 02:07





Fügen Sie Folgendes zu /etc/apt.conf oder /etc/apt/apt.conf.d/50remount hinzu

DPkg::Pre-Install-Pkgs {"mount -o remount,exec /tmp";};
DPkg::Post-Invoke {"mount -o remount /tmp";};

6
2017-08-30 02:37



Ich habe ersetzt mount durch /bin/mount falls PATH geändert wird. Du wirst es nie wissen. - Lekensteyn


Obwohl für die meisten zusätzlichen Sicherheitsmaßnahmen, die Sie möglicherweise implementieren möchten, Workarounds existieren, werden selbst die am leichtesten umgehenden Sicherheitsmaßnahmen (wie das Mounten von / tmp noexec oder das Ausführen von SSH auf einem alternativen Port) automatisierte oder skriptgesteuerte Angriffe vereiteln, die auf den Standardwerten basieren Funktionieren. Es schützt Sie nicht vor einem entschlossenen und sachkundigen Angreifer, aber weit über 99% der Zeit stehen Sie einem entschlossenen oder sachkundigen Angreifer nicht gegenüber. Stattdessen verteidigst du dich gegen ein automatisiertes Angriffsskript.


4
2017-08-21 03:17





Zuerst: Es deckt viele verschiedene Angriffsfälle ab Es auszuschalten, weil es ein paar bekannte Wege gab (einige davon sogar behoben) ist seltsam. Angreifer, die Code nach / dev / shm oder / tmp herunterladen, tun dies häufig.

Bei der Tiefenverteidigung geht es darum, die gängigsten Wegpunkte zu sichern. Jeder, der sie stoppt, macht Ihr System überlebensfähiger. Nicht sicher. Aber es wird auch haben eine Chance. Wenn sie ihre sekundäre Nutzlast nicht abrufen können, ist das eine ziemlich gute Chance, die Sie bekommen.

  • Es kann auch durch Benutzereinschränkungen von iptables gestoppt werden.
  • Es könnte auch von SELinux gestoppt werden.
  • Es könnte auch sein nicht aufgrund eines leicht zugänglichen anderen Exploits gestoppt werden.

Der Punkt ist, es so schwer wie Sie zu machen leicht kann und 99% der Angriffe ausschneiden.

Zweite:  Es stoppt schlechtes Üben (Ausführen von Sachen aus temp, Ausführen wichtiger Anwendungsinstallationen über / tmp anstelle eines Benutzers tmpdir), wobei Daten in / tmp belassen werden. Benutzerdefinierte Installationsprogramme normalerweise verstehe TMPDIR Außerdem: selbst wenn nicht: Installationszeit, als eine punktuelle Aktion, ist kein gültiger Grund, ein Sicherheitsproblem auszuschalten permanent.

Dritte: Wenn Sie anonyme Namespaces in / tmp (ein "Feature") betrachten, wollen Sie wirklich einschränken, was dort abgelegt ist und von dort aus laufen.

Weiter: Bequemlichkeit ist dabei kein relevanter Faktor. Vorausgesetzt, wir betreiben Server für Geld und für einen Zweck: Wir sind für dieses Zeug verantwortlich. "Oh, ich habe nicht gesperrt / tmp, weil ich dann ein paar Minuten brauche, wenn ich meine Software nächstes Jahr aktualisiere". Sicher wird es nicht nur diese eine Sache sein, die zwischen Erpressung und Rechtschaffenheit steht. Ein guter Grund? Ich denke nicht.

Wie wäre es mit diesem:

"Wir haben gelernt, dass Feinde ohne Vorankündigung angreifen können. Sie könnten auch   Verwende Hunderte von Spionen, um das Essen zu vergiften. Also hörten wir auf zu verteilen   Waffen an unsere Soldaten. "

Warte was?

Es gibt noch andere Maßnahmen, die viel mehr Aufwand, Erfahrung und Glück erfordern, um ein System zu sichern, und zu wissen, dass Menschen nur wenig Geld und Lebensspanne haben und auch Zeit mit ihren Familien verbringen möchten: Überspringen Sie nicht die einfachen Dinge.


2
2017-11-21 10:44





Es gibt Anwendungen, die / tmp für die Installation benötigen. Bei einem früheren Job, bevor ich dort ankam, hatten die Admins / tmp noexec eingerichtet, aber ich entdeckte, dass das db2-Paket nicht installiert werden konnte. Selbst wenn Sie das db2-Paket irgendwo anders entpacken, kopiert die Installationsprozedur einige Dateien nach / tmp und erwartet, dass sie ausgeführt werden können, was natürlich mit verweigerter Berechtigung fehlgeschlagen ist. Wenn Sie nicht wissen, dass das Dateisystem mounted noexec ist, könnte es ein wenig irreführend sein. Es war nur in der Lage, die Installation fortzusetzen, nachdem ich / tmp ohne noexec neu installiert habe.

Wie auch immer, der Punkt ist, dass mindestens ein kommerzielles Produkt erfordert, dass / tmp nicht noexec gemountet wird, und es könnte andere geben. Ich habe keinen wirklich zwingenden Grund dafür gefunden. Wenn Sie eine bessere Sicherheit wünschen, würde ich stattdessen mit selinux gehen.


1
2017-08-25 13:13



Eine Analyse eines Exploits für die Samba-Schwachstelle, die von einem noexec / tmp gestoppt werden würde: bobao.360.cn/learning/detail/4168.html (Chrome's Google Translate empfohlen. Es würde den anfänglichen Exploit sowie einen großen Teil der Payload unterbrechen ...) (Sie können viele übliche automatische Exploits auf diese Weise durchbrechen ....). mount -o remount,exec /tmp funktioniert, wenn du Sachen installieren musst ... (Ja, es ist trivial, herumzuarbeiten, aber viele Angreifer scheinen das nicht zu stören ...) - Gert van den Berg