Erklärung von nodev und nosuid in fstab

Ich sehe diese beiden Optionen ständig im Web vorgeschlagen, wenn jemand beschreibt, wie man ein tmpfs oder ramfs mounten kann. Oft auch mit noexec aber ich interessiere mich speziell für nodev und nosuid. Ich hasse es einfach blind zu wiederholen, was jemand vorgeschlagen hat, ohne wirklich zu verstehen. Und da ich diesbezüglich nur Anweisungen zum Kopieren / Einfügen im Netz sehe, frage ich hier.

Dies stammt aus der Dokumentation:
nodev - Blockieren Sie keine speziellen Geräte im Dateisystem.
nosuid - Blockiert die Operation von suid- und sgid-Bits.

Aber ich möchte eine praktische Erklärung, was passieren könnte, wenn ich diese beiden auslasse. Angenommen, ich habe tmpfs oder ramfs (ohne diese beiden genannten Optionen) konfiguriert, auf die ein bestimmter Benutzer (kein Root-Benutzer) auf dem System zugreifen kann (Lesen + Schreiben). Was kann dieser Benutzer tun, um dem System Schaden zuzufügen? Ausgenommen der Fall, dass bei RAMs der gesamte verfügbare Systemspeicher verbraucht wird

linux security fstab

— Ivan Kovacevic
quelle

Dies ist eine gute Antwort auf Ihre Frage

— Elliptical view

Sie müssen dies nicht als harte Regel blind befolgen. Die Gründe für sicherheitsrelevantere Situationen lauten jedoch wie folgt.

Die Option nodev mount gibt an, dass das Dateisystem keine speziellen Geräte enthalten darf: Dies ist eine Sicherheitsmaßnahme. Sie möchten nicht, dass ein für Benutzer weltweit zugängliches Dateisystem wie dieses das Potenzial zur Erstellung von Zeichengeräten oder zum Zugriff auf zufällige Gerätehardware hat.
Die Option nosuid mount gibt an, dass das Dateisystem keine festgelegten Benutzer-ID-Dateien enthalten kann. Es ist sinnvoll, setuid-Binärdateien in einem Dateisystem mit Schreibzugriff auf die Welt zu verhindern, da das Risiko einer Root-Eskalation oder einer anderen Schrecklichkeit besteht.

Ich verwende diese Parameter nicht oft, nur auf öffentlich zugänglichen Systemen, bei denen andere Compliance-Aspekte berücksichtigt werden.

— ewwhite
quelle

Ich habe tatsächlich ein öffentlich zugängliches System, da Software unter diesem Konto ausgeführt wird, das dem Netz ausgesetzt ist. Ich frage mich also, was wäre, wenn hier Szenarien wären. Was ist, wenn jemand durch eine Sicherheitsanfälligkeit Zugriff auf die Shell erhält? Natürlich gibt es andere Dinge, die er tun könnte, um Rechte zu eskalieren, aber ich möchte sie lieber minimieren. Ich frage mich zum Beispiel, ob der Benutzer dieses Flag nicht immer noch ändern kann, unabhängig davon, ob das Dateisystem dies zulässt oder nicht. Verhindert die Option nosuid dann nur versehentlich schlecht konfigurierte Software (von einem Root)? Oder kann ein Benutzer es alleine ausnutzen?

— Ivan Kovacevic

@IvanKovacevic Sie müssen nicht die empfohlenen Einhängeoptionen für das Dateisystem verwenden. Sie sind dazu da, den Angriffsvektor zu reduzieren. Das Untersuchen von Was-wäre-wenn-Szenarien kann jedoch den Rahmen dieser Frage sprengen.

— ewwhite

@ewwhite: bzgl. nosuidwird das setuid bit nicht ignoriert? (anstelle von The nosuid mount option specifies that the filesystem cannot contain set userid files)

— user2284570