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


39

Viele Leute (einschließlich des Securing Debian Manual ) empfehlen, /tmpmit den noexec,nodev,nosuidOptionen zu mounten. Dies wird im Allgemeinen als ein Element einer Tiefenverteidigungsstrategie dargestellt, indem die Eskalation eines Angriffs verhindert wird, bei dem eine Datei geschrieben wird, oder ein Angriff eines Benutzers mit einem legitimen Konto, aber keinem anderen beschreibbaren Bereich.

Im Laufe der Zeit bin ich jedoch auf Argumente gestoßen (am prominentesten von Debian / Ubuntu-Entwickler Colin Watson) noexec, die aus ein paar möglichen Gründen eine nutzlose Maßnahme sind:

  1. Der Benutzer kann /lib/ld-linux.so <binary>versuchen, 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

In Anbetracht dieser Argumente ist das potenzielle Bedürfnis nach mehr Konfiguration (z. B. nach debconfeinem ausführbaren temporären Verzeichnis) und der potenzielle Komfortverlust eine lohnende Sicherheitsmaßnahme? Welche anderen Löcher, die Sie kennen, ermöglichen die Umgehung?


1
@neoice: Ich habe gehört, dass Anwendungen gelegentlich abstürzen, wenn / tmp nicht ausführbar ist. Ich habe es aber noch nicht gesehen. Schau dir TuxGuitar-1.2 an ... es passiert. Wird nicht gestartet, wenn / tmp nicht ohne die Option noexec gemountet ist, da dort die Bibliotheken entpackt werden und versucht wird, sie zu laden.

Site Recovery Manager von VMware führt Skripts über "/ tmp" aus: Die IP-Anpassung schlägt während eines Failovers oder eines Testfailovers eines Wiederherstellungsplans in vCenter Site Recovery Manager (2021083) fehl

1
Ich weiß, dass das Komprimierungsprogramm mit dem Namen snappy eine .so-Datei in / tmp ablegt und nicht ausgeführt werden kann, wenn noexec gemountet ist. (es wird standardmäßig in cassandra und kafka verwendet) IMHO ist dies ein Grund, nicht bissig zu verwenden, sondern ein Grund, nicht / tmp noexec
jorfus 21.07.17

Antworten:


31

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

Moderne Kernel beheben die /lib/ld-linux.soLücke, sodass es nicht möglich ist, ausführbare Seiten aus einem noexecDateisystem abzubilden .

Der Dolmetscher-Punkt ist sicherlich immer noch ein Problem, obwohl ich weniger von einem halte, als die Leute behaupten könnten. Der Grund, auf den ich kommen kann, ist, dass es zahlreiche Sicherheitslücken in Bezug auf die Eskalation von Berechtigungen gab, die darauf beruhten, dass bestimmte fehlerhafte Systemaufrufe ausgeführt wurden. Ohne einen Angreifer, der eine Binärdatei bereitstellt, wäre es viel schwieriger, böse Systemaufrufe zu tätigen. Außerdem sollten Skriptinterpreter nicht privilegiert sein (ich weiß, dass dies in der Vergangenheit manchmal nicht der Fall war, wie bei einem Suid Perl) und daher ihre eigene Verwundbarkeit benötigen, um bei einem Angriff nützlich zu sein. Anscheinend ist es möglich , zumindest Python zu verwenden, um einige Exploits auszuführen.

Viele "vorgefertigte" Exploits versuchen möglicherweise, ausführbare Dateien zu schreiben und auszuführen /tmp, und noexecverringern so die Wahrscheinlichkeit, dass sie zu einem Skriptangriff führen (etwa im Fenster zwischen der Offenlegung von Sicherheitslücken und der Installation von Patches).

So gibt es immer noch einen Sicherheitsvorteil der Montage /tmpmit noexec.

Wie in beschrieben Debians Bugtracker , Einstellung APT::ExtractTemplates::TempDirin apt.confein Verzeichnis , das nicht ist noexecund zugänglich root würde die Debconf Sorge vermeiden.


Ich habe jedoch gehört, dass Anwendungen gelegentlich abstürzen, wenn / tmp nicht ausführbar ist. Ich habe es aber noch nicht gesehen.
neoice

Wie in dem in der Frage verlinkten Handbuch erwähnt, wird die Vorkonfiguration des Debconf-Pakets beeinträchtigt, ohne dass eine Alternative eingerichtet wird.
Phil Miller

2
Ja, noexec ist eine sehr gute zusätzliche Sicherheitsschicht, und ich habe nicht gesehen, dass die Dinge dadurch Schaden anrichten. Die Paketinstallation ist das einzige, und selbst das kann umgangen werden, wie die Antworten hier zeigen. Als meine Lösung habe ich einen Alias ​​wie diesen: alias update = "mount -o exec, remount / tmp && apt-get update && apt-get upgrade && mount -o noexec, remount / tmp"
Janne Pikkarainen

1
Ich denke, es ist ungewöhnlich, aber Pakete, die geschrieben wurden, um etwas von / tmp außerhalb eines Paketinstallationskontexts auszuführen, existieren (z. B. die aktuelle Version der Middleware für die Verwendung der belgischen elektronischen Identitätskarten).
Equaeghe

equaeghe: Was für ein Paket ist das? Es sollte wahrscheinlich als Fehler gemeldet werden. Ich bin bereit zu wetten, dass es eine Sicherheitslücke gibt, die auch darin zu finden ist, wie sie verwendet wird.
Phil Miller

7

Für viele Debian-Pakete muss / tmp ausführbar sein, 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 genau diesen Fehler erhalten, als ich gerade heute einen aktualisierten Kernel für den Stable-Zweig installiert habe.

Es sieht also so aus, als ob Debian (und Derivate?) Noch nicht bereit ist, / tmp noexec einzuhängen ...


6

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
Ich habe ersetzt mountdurch /bin/mountfür den Fall, dass PATH geändert wird. Du wirst es nie wissen.
Lekensteyn,

4

Obwohl es für die meisten zusätzlichen Sicherheitsmaßnahmen, die Sie möglicherweise implementieren, Problemumgehungen gibt, verhindern selbst die am leichtesten zu umgehenden Sicherheitsmaßnahmen (wie das Mounten von / tmp noexec oder das Ausführen von SSH auf einem alternativen Port) automatisierte oder skriptgesteuerte Angriffe, die auf den Standardeinstellungen basieren Funktionieren. Es wird Sie nicht vor einem entschlossenen und sachkundigen Angreifer schützen, aber in weit über 99% der Fälle werden Sie keinem entschlossenen oder sachkundigen Angreifer gegenüberstehen. Stattdessen verteidigen Sie sich gegen ein automatisiertes Angriffsskript.


2

Erstens: Es deckt viele verschiedene Angriffsfälle ab. Es ist komisch, es auszuschalten, weil es einige bekannte Möglichkeiten gab (von denen einige sogar behoben wurden). 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. Durch jede Unterbrechung bleibt Ihr System überlebensfähig. Nicht sicher. Aber es wird auch eine Chance haben . Wenn sie ihre sekundäre Nutzlast nicht abrufen können, haben Sie eine gute Chance.

  • Es kann auch durch Benutzerbeschränkungen von iptables gestoppt werden.
  • Es könnte auch von SELinux gestoppt werden.
  • Es kann auch sein, dass es aufgrund eines anderen Exploits, auf den leicht zugegriffen werden kann, nicht gestoppt werden kann.

Der Punkt ist es so schwer zu machen , wie Sie leicht können, und 99% der Angriffe ausgeschnitten.

Zweitens: Es verhindert schlechte Praktiken (Ausführen von temporären Dateien, Ausführen von Hauptanwendungsinstallationen über / tmp anstelle eines Benutzers tmpdir), wobei Daten in / tmp verbleiben. Benutzerdefinierte Installer verstehen in der Regel TMPDIR. Auch wenn dies nicht der Fall ist, ist die Installationszeit als Zeitpunktaktion kein gültiger Grund, um ein Sicherheitsproblem dauerhaft zu deaktivieren .

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

Forth: Convenience spielt dabei keine Rolle. Vorausgesetzt, wir betreiben Server für Geld und für einen Zweck: Wir sind für dieses Zeug verantwortlich. "Oh, ich habe / tmp nicht gesperrt, weil ich dann ein paar Minuten mehr brauche, wenn ich nächstes Jahr meine Software aktualisiere." Sicherlich wird es nicht nur diese eine Sache sein, die zwischen Erpressung und Ordnung steht. Ein guter Grund? Ich glaube nicht

Wie wäre es mit diesem:

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

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 nur über begrenztes Geld und eine begrenzte Lebensdauer verfügen und auch gerne Zeit mit ihren Familien verbringen möchten: Überspringen Sie nicht die einfachen Dinge.


1

Es gibt Anwendungen, für deren Installation / tmp ausführbar sein muss. Bei einem früheren Job, bevor ich dort ankam, hatten die Administratoren / tmp noexec eingerichtet, aber ich stellte fest, dass das Paket db2 nicht installiert werden konnte. Selbst wenn Sie das db2-Paket an einer anderen Stelle entpacken, kopiert die Installationsprozedur einige Dateien nach / tmp und erwartet, dass sie ausgeführt werden können, was natürlich fehlschlug, wenn die Berechtigung verweigert wurde. Wenn Sie nicht wissen, dass das Dateisystem noexec gemountet ist, ist dies möglicherweise etwas irreführend. Die Installation konnte erst fortgesetzt werden, nachdem ich / tmp ohne noexec erneut gemountet habe.

Der Punkt ist jedenfalls, dass mindestens ein kommerzielles Produkt / tmp benötigt, um nicht noexec gemountet zu werden, und es könnte auch andere geben. Ich habe keinen wirklich überzeugenden Grund dafür gefunden. Wenn Sie mehr Sicherheit wünschen, würde ich stattdessen mit Selinux arbeiten.


Eine Analyse eines Exploits für die Samba-Sicherheitsanfälligkeit, die von noexec / tmp: bobao.360.cn/learning/detail/4168.html (Google-Übersetzung von Chrome empfohlen) gestoppt würde großer Teil der Nutzlast ...) (Auf diese Weise können Sie viele gängige automatische Exploits unterbrechen ....). mount -o remount,exec /tmpfunktioniert, wenn Sie etwas installieren müssen ... (Ja, es ist trivial, dies zu umgehen, aber viele Angreifer scheinen sich nicht darum zu kümmern ...)
Gert van den Berg
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.