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

Lösung 1:

Hier sind die Argumente für die Nützlichkeit, die mir bisher eingefallen sind:

Moderne Kernel beheben den /lib/ld-linux.so Loch, sodass es nicht in der Lage ist, ausführbare Seiten von einem noexec abzubilden Dateisystem.

Der Punkt der Dolmetscher ist sicherlich immer noch ein Problem, obwohl ich denke, dass es weniger eines ist, als die Leute vielleicht behaupten. Die Argumentation, die ich mir vorstellen kann, ist, dass es zahlreiche Schwachstellen bei der Rechteausweitung gegeben hat, die auf bestimmten fehlerhaften Systemaufrufen beruhten. Ohne einen Angreifer, der eine Binärdatei bereitstellt, wäre es viel schwieriger, böse Systemaufrufe durchzuführen. Außerdem sollten Skriptinterpreter nicht privilegiert sein (ich weiß, dass dies in der Vergangenheit manchmal nicht der Fall war, wie z. B. bei einem Suid-Perl), und würden daher ihre eigene Schwachstelle benötigen, um bei einem Angriff nützlich zu sein. Anscheinend ist es möglich, zumindest einige Exploits mit Python auszuführen.

Viele vorgefertigte Exploits versuchen möglicherweise, ausführbare Dateien in /tmp zu schreiben und auszuführen , und so noexec verringert die Wahrscheinlichkeit, auf einen Skriptangriff zu fallen (z. B. im Fenster zwischen der Offenlegung der Schwachstelle und der Patch-Installation).

Daher bietet das Mounten von /tmp immer noch einen Sicherheitsvorteil mit noexec .

Wie in Debians Bugtracker beschrieben, setzen Sie APT::ExtractTemplates::TempDir in apt.conf in ein Verzeichnis, das nicht noexec ist und zugänglich für root würde die Sorge um Debconf beseitigen.

Lösung 2:

Viele Debian-Pakete erfordern, dass /tmp ausführbar ist, damit das Paket installiert werden kann. Diese werden oft als Fehler markiert (mit dem Schweregrad „normal“/„Wunschliste“):

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

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

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

Lösung 3:

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

Lösung 4:

Auch wenn es für die meisten zusätzlichen Sicherheitsmaßnahmen, die Sie möglicherweise implementieren, Problemumgehungen gibt, vereiteln selbst die am einfachsten zu umgehenden Sicherheitsmaßnahmen (wie z Funktionieren. Es schützt Sie nicht vor einem entschlossenen und sachkundigen Angreifer, aber in weit über 99 % der Fälle werden Sie es nicht mit einem entschlossenen oder sachkundigen Angreifer zu tun haben. Stattdessen verteidigen Sie sich gegen ein automatisiertes Angriffsskript.

Lösung 5:

Erstens: Es deckt viele verschiedene Angriffsfälle ab. Es ist seltsam, es auszuschalten, weil es einige bekannte Möglichkeiten gab (von denen einige sogar behoben wurden). Angreifer laden Code auf /dev/shm herunter oder /tmp ist eine übliche Sache, die sie tun.

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

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

Der Punkt ist, es so schwer wie möglich einfach zu machen kann und 99 % der Angriffe unterbindet.

Zweitens: Es stoppt schlechte Praktiken (Ausführen von Sachen von temp, Ausführen wichtiger Anwendungsinstallationen über /tmp anstelle eines Benutzer-tmpdir), wobei die Daten in /tmp verbleiben .Benutzerdefinierte Installationsprogramme verstehen TMPDIR normalerweise Außerdem:selbst wenn nicht:Die Installationszeit als Point-in-Time-Aktion ist kein triftiger Grund, ein Sicherheitsproblem dauerhaft zu deaktivieren .

Dritter: Berücksichtigung anonymer Namespaces in /tmp (ein "Feature"), möchten Sie wirklich einschränken, was dort abgelegt und von dort aus ausgeführt wird.

Viertens: Bequemlichkeit ist dabei kein relevanter Faktor. Angenommen, wir betreiben Server für Geld und für einen bestimmten Zweck:Wir sind für dieses Zeug verantwortlich. „Oh, ich habe /tmp nicht gesperrt denn dann brauche ich beim Software-Update im nächsten Jahr ein paar Minuten mehr. „Sicher wird es nicht nur diese eine Sache sein, die zwischen Erpressung und Guthaben steht. Ein guter Grund? Ich glaube nicht.“ P>

Wie wäre es mit diesem hier:

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

Warte, WAS?

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