Es gibt eine noch einfachere Möglichkeit, die Berechtigung "Ausführen" zu umgehen: Kopieren Sie das Programm in ein Verzeichnis, das Sie besitzen, und setzen Sie das Bit "Ausführen".

Die Berechtigung "Ausführen" ist keine Sicherheitsmaßnahme . Die Sicherheit wird auf einer niedrigeren Ebene bereitgestellt, wobei das Betriebssystem bestimmte Aktionen einschränkt. Dies geschieht, weil auf vielen Unix-ähnlichen Systemen (insbesondere in den Tagen von Ritchie und Thompson) davon ausgegangen wird, dass der Benutzer seine eigenen Programme erstellen kann. In einer solchen Situation ist die Verwendung der Berechtigung "Ausführen" als Sicherheitsmaßnahme sinnlos, da der Benutzer einfach eine eigene Kopie eines vertraulichen Programms erstellen kann.

Als konkretes Beispiel wird fdisk als nicht privilegierter Benutzer, der versucht, die Partitionstabelle der Festplatte zu verschlüsseln:

  $ / sbin / fdisk / dev / sda Willkommen bei fdisk (util-linux 2.24.1) Bleiben Sie nur im Speicher, bis Sie sich entscheiden, sie zu schreiben. Seien Sie vorsichtig, bevor Sie den Schreibbefehl verwenden. Der Partitionstyp 'Linux' wurde in 'Hidden NTFS WinRE' geändert. Befehl (m für Hilfe): wfdisk: Disklabel konnte nicht geschrieben werden : Ungültiger Dateideskriptor  

In dieser letzten Zeile wird fdisk versucht, einen "Schreib" -Dateideskriptor für die Festplatte abzurufen, was aufgrund des von mir ausgeführten Benutzers fehlschlägt Es hat keine Berechtigung, dies zu tun.

Die Berechtigung "Ausführen" dient zwei Zwecken: 1) dem Betriebssystem mitzuteilen, welche Dateien Programme sind, und 2) dem Benutzer mitzuteilen welche Programme sie ausführen können. Beides ist eher ratsam als obligatorisch: Sie können ein perfekt funktionierendes Betriebssystem ohne die Erlaubnis erstellen, aber es verbessert die Benutzererfahrung.

Wie R .. hervorhebt, gibt es einen bestimmten Fall, in dem "Ausführen" "Berechtigung wird aus Sicherheitsgründen verwendet: Wenn für ein Programm auch das Bit" setuid "gesetzt ist. In diesem Fall kann mit der Berechtigung "Ausführen" eingeschränkt werden, wer das Programm ausführen darf. Bei jeder Methode zum Umgehen der Berechtigung "Ausführen" wird auch der Status "Setuid" entfernt, sodass hier kein Sicherheitsrisiko besteht.

Sie können das Ausführungsbit, aber nicht das Lesebit für eine ausführbare Datei setzen. Auf diese Weise kann niemand die Datei kopieren, aber die Leute können sie trotzdem ausführen.

Dies ist heute ziemlich sinnlos, da a) es nur für kompilierte Programme funktioniert, nicht mit Skripten (auf den meisten Systemen) ;; b) Heutzutage, da 90% aller Unixe Linux sind, können Benutzer ausführbare Dateien von nahezu jedem Ort kopieren, und c) der Speicherplatz, den eine kopierte ausführbare Datei belegt, spielt keine Rolle.

Trotzdem gab es sie verwendet dies früher.

Das Unix-System, das ich vor 30 Jahren in der Schule verwendet habe, war in Bezug auf RAM und Speicherplatz sehr begrenzt. Insbesondere das Dateisystem / usr / tmp war sehr klein, was zu Problemen führte, wenn jemand versuchte, ein großes Programm zu kompilieren. Natürlich sollten die Schüler sowieso keine "großen Programme" schreiben; Bei großen Programmen handelte es sich normalerweise um Quellcodes, die von "irgendwo" kopiert wurden. Viele von uns haben / usr / bin / cc nach / home / <myname> / cc kopiert und dd verwendet, um die Binärdatei zu patchen und / tmp anstelle von / usr / tmp , das größer war. Dies verschlimmerte das Problem natürlich nur noch - der von diesen Kopien belegte Speicherplatz war damals von Bedeutung, und jetzt wurde / tmp regelmäßig gefüllt, sodass andere Benutzer ihre Dateien nicht einmal bearbeiten konnten. Nachdem sie herausgefunden hatten, was passiert war, führten die Systemadministratoren einen chmod go-r / bin / * / usr / bin / * durch, der das Problem "behebte" und alle unsere Kopien des C-Compilers löschte.

Eine andere Verwendung besteht darin, der Shell mitzuteilen, welche Dateien ausgeführt werden sollen und welche nicht. Sie möchten nicht, dass eine zufällige Textdatei ausgeführt wird, weil Sie ihren Namen eingegeben haben. Das x-Bit bietet eine Möglichkeit, dies zu verhindern. (Heutzutage konnte die Shell nur den Anfang der Datei betrachten und sie nur ausführen, wenn sie mit #! beginnt, dies wurde jedoch viel später eingeführt.) Die Vervollständigungsfunktion von bash schlägt ebenfalls nur Dateien mit ausführbaren Bits vor, wenn Sie einen Befehl eingeben.

Es gibt eine vorgefertigte Möglichkeit, eine beliebige Datei auszuführen: Übergeben Sie sie als Argument an den dynamischen Linker (der der geeignete Interpreter für eine dynamisch geladene ausführbare Datei ist). Z.B. unter Linux

  cp / bin / ls / tmp / chmod -x /tmp/ls/lib/ld-linux.so.2 / tmp / ls  

Dies unterliegt jedoch der gleichen Einschränkung wie das Lesen der Datei und das Springen zum Code: Die setuid -Bits werden nicht ausgewertet.

Früher haben wir dies häufig getan Binärdateien wie /bin/su:

  -rwsr-xr-- Wurzelrad ... / bin / su  

Nur Mitglieder der Gruppe Rad , die von den Systemadministratoren auf Personen zugeschnitten wurden, die das Kennwort root kennen, können den Befehl su ausführen. Selbst wenn in dieser Binärdatei ein Pufferüberlauf vorhanden wäre, der es Anrufern ermöglicht, die Sicherheit zu umgehen, kann der Exploit nur von Personen verwendet werden, die das Kennwort ohnehin kennen.

Ich bin überrascht, dass niemand sonst auf eine andere Verwendung von + x-Bit-Verzeichnissen hingewiesen hat. Vielleicht sind Sie nach der Ausführung von (Beispiel) etwas in / bin (Shell-Skript oder auf andere Weise), aber es gibt mehr Bits als Dateien auszuführen (natürlich ist ein Verzeichnis eine Datei, aber es ist eine andere Art von Datei).

Wenn Sie + x Zugriff auf ein Verzeichnis haben, aber -r auf dasselbe Verzeichnis, haben Sie die folgenden Funktionen:

• Wenn Sie den Namen einer Datei kennen ( oder Verzeichnis) in diesem Verzeichnis können Sie es auflisten (z. B. ls darauf). Sie müssen den Namen jedoch kennen.
• Sie können ihn nicht ändern (über den Befehl cd oder den Systemaufruf chdir).

Wenn Sie jedoch -x haben und + r können Sie Folgendes tun:

• Sie können nicht in das Verzeichnis wechseln (wie oben beschrieben).
• Sie können die Dateien auflisten. Da Sie jedoch keinen + x-Zugriff auf das Verzeichnis haben, können Sie nicht auf die Dateien selbst zugreifen.
• Dies bedeutet auch, dass Sie nicht aktualisieren können (nur Zeitstempel oder auf andere Weise) und sie auch nicht in einem Texteditor öffnen können (oder cat oder ...).

Wenn Sie + rx haben, können Sie all das tun (außer dass Sie + w benötigen, um in das Verzeichnis selbst zu schreiben, das heißt Neue Dateien erstellen, Dateien bearbeiten funktioniert, Entfernen nicht, Erstellen nicht)

Und ja, dies bedeutet, dass einige Personen Dateien anzeigen oder bearbeiten können, aber nur, wenn sie den genauen Pfad dazu kennen ( solange sie das Recht haben, sie zu bearbeiten). Und ja: ls ist eine Liste und das gilt für die Suche nach Verzeichnissen. Zusammenfassend lässt sich sagen, dass die Ausführung eines Verzeichnisses in dieses Verzeichnis geändert wird (aus welchem ​​Grund auch immer). Natürlich sind die Teile zusammen wirklich wichtig.

Wenn Sie aus irgendeinem Grund den Binärcode geheim halten möchten, können Sie das Programm ausführbar machen, ohne lesbar zu sein. Dies ist nicht sinnvoll, wenn diese Benutzer physischen Zugriff auf den Computer haben. Es ist auch nicht sinnvoll, wenn der Quell- oder Binärcode allgemein verfügbar ist. Dies ist also ein ziemlich begrenzter Anwendungsfall.

Wenn das Programm ein Setuid- oder Setgid-Bit hat, bewirkt der Ausführungszugriff mehr als das, was durch Lesen der Binärdatei erreicht werden kann. Ein Ansatz besteht darin, eine ausführbare setuid-Datei zu erstellen, die nur für eine bestimmte Gruppe ausführbar ist. Wenn es weltweit lesbar war, konnten Personen außerhalb dieser Gruppe es immer noch nicht kopieren und das setgid-Bit in der ursprünglichen ausführbaren Datei verwenden. (In den meisten Fällen verwende ich jedoch lieber setgid als setuid und verwende dann die Gruppe im Verzeichnis, um zu steuern, wer auf die ausführbare Datei zugreifen kann.)

Normalerweise wird das ausführbare Bit einfach verwendet, um anzugeben, welche Dateien Programme sind an erster Stelle. Auf diese Weise kann die Fertigstellung besser funktionieren und Sie führen nicht versehentlich unerwünschte ausführbare Dateien aus.

Wenn Sie verhindern möchten, dass Benutzer eine ausführbare Datei kopieren und ausführen, können Sie Home-Verzeichnisse mit noexec . Damit dies sinnvoll ist, müssen Sie noexec für jedes Dateisystem verwenden, in das der Benutzer alles schreiben kann.

Die Berechtigung zum Ausführen von Bits wird vom Kernel beim Ausführen des Systemaufrufs exec (2) (und Cousins) überprüft. Sie benötigen es nur, um Programme auf Kernel-Ebene auszuführen.

Nur Programme mit diesem Bit (je nachdem, was Sie als Eigentümer, Gruppe oder andere trifft, wird überprüft) können exec sein () ed vom Kernel.

Eine andere Sache ist, was die Shell tut, wenn sie ein Shell-Skript oder Perl interpretiert, oder welchen Interpreter Sie auch haben mögen. Bei Skripten überprüft der Kernel das #! ... am Anfang der Datei als magische Zahl und startet die dort angegebene Shell (Sie benötigen auch die Ausführungsberechtigung für die Shell) und Sie benötigen Leseberechtigungen für dieses Skript, da die Shell es öffnen und lesen muss, um interpretiert zu werden. Für Shell-Skripte benötigen Sie Leseberechtigung sowie Ausführungsberechtigung. Für Shell-Skripte benötigen Sie jedoch nur eine Leseberechtigung, da Sie ein Shell-Skript immer ausführen können, indem Sie die Shell ausführen und das Shell-Skript als Parameter (oder Eingabedatei) übergeben )

Natürlich kann das Ausführungsbit, wie bereits erwähnt, umgangen werden, indem das Programm kopiert und ausführbar gemacht wird, aber Sie können es nicht kopieren, wenn Sie es nicht gelesen haben Berechtigungen zum Erstellen dieser Kopie (Sie können sie weiterhin ausführen).

Versuchen Sie (natürlich als Root), die Berechtigungen in ls (1) zu ändern und 0111 ( --- x - x - x ) und versuchen Sie, eine ausführbare Kopie davon zu erstellen, und sehen Sie, wie Sie Ihre ausführbare Kopie nicht erhalten können, selbst wenn Sie fortfahren in der Lage sein, es auszuführen.

In Verzeichnissen bedeutet das Ausführungsbit etwas anderes. Der Kernel verwendet die Berechtigung ' x ', wenn er den Pfad durchläuft (in der Kernelfunktion namei () ). Wenn Sie also keine Ausführungsberechtigungen für ein Verzeichnis haben, können Sie dies nicht Verwenden Sie es entweder oder die Dateien, auf die Sie zugreifen können. Selbst Sie können einen Verzeichnisinhalt mit Leseberechtigungen lesen, aber Sie können nicht auf die darin enthaltenen Dateien zugreifen. Im Gegenteil, Sie können Ausführungsberechtigungen für ein Verzeichnis haben, aber keinen Lesezugriff, und Sie können die darin enthaltenen Dateien verwenden, aber den Verzeichnisinhalt nicht sehen.