Welche Zugriffsrechte kann der Superuser nicht verletzen?

Fr. Br. George sagte in einem seiner Vorträge (auf Russisch), dass es einige Zugriffsrechte gibt, die der Superuser nicht verletzen kann. Das heißt, es gibt einige Zugriffsrechte, die dem Superuser verbieten können, etwas zu tun.

Ich konnte diese Informationen im Internet nicht finden und bin gespannt, was sie sind. Dies hängt wahrscheinlich mit der Kernausführung des Systems zusammen, nicht wahr? Vielleicht kann er einige Systemprozesse nicht stoppen? Oder kann er vielleicht keinen Prozess im Real-Modus ausführen?

Diese Frage hat nichts mit SELinux zu tun (George hat direkt vor der Frage darüber gesprochen).

Zugriff auf root verweigert :

rootkann direkter Netzwerkzugriff verweigert werden. Dies ist bei mit dem Internet verbundenen Hosts nützlich, da Sie sich dann anmelden smithmüssen sudo.

Einige Sachen, die root nicht machen kann :

Dies ist NICHT aus Mangel an Privilegien. Ich kann nichts sehen, was root nicht tun konnte. Einige technische Probleme können jedoch als "verboten" eingestuft werden.

Ich bin root. Warum kann ich diese Datei nicht erstellen / löschen, während es normale Benutzer können?

Sie befinden sich auf einer NFS / Samba-Freigabe und haben keine spezifische ( access=) Autorisierung erhalten. Normale Benutzer verstoßen gegen das Common Law. (siehe local vs remote root weiter unten)

Ich bin root, warum kann ich diesen Prozess nicht beenden?

Es liegt eine ausstehende E / A vor und das physische Laufwerk / die Remote-LUN wurde getrennt. Der Vorgang kann nur durch einen Neustart abgebrochen werden.

Ich bin root, wie bekomme ich das Passwort des Archemars?

Sie können su - archemardas Kennwort des Archemars ändern, ohne das vorherige zu kennen, können es jedoch nicht lesen (außer bei einem Key Logger), da Kennwörter mit einem One-Way-Hash gespeichert werden.

lokale vs remote root

• Sie können auf Ihrer Station / Ihrem PC als Root angemeldet sein und eine NFS-Freigabe eines Unternehmens / einer Hochschule / Universität / eines Anbieters verwenden.
• Als nächstes können Sie sich auf dem Computer, auf dem NFS exportiert wird, nur nicht als Root anmelden.

Jetzt

cp /bin/bash /nfs/home/me/bash
chown root /nfs/home/me/bash
chmod u+s /nfs/home/me/bash

Melden Sie sich einfach am NFS-Server an, führen ./bashSie ihn aus und Sie sind root auf dem Firmen- / Universitätsserver.

Im Normalfall ist dies falsch - der Superuser verfügt über Berechtigungen für alle vom System bereitgestellten Funktionen (1). Wenn Sie SELinux in den Mix werfen, bricht diese Regel zusammen. Mit SELinux ist es möglich, sogar die Rechte von root einzuschränken, um bestimmte Aktionen zu verbieten. Die nicht zulässigen Aktionen hängen jedoch stark von der SELinux-Konfiguration des lokalen Computers ab. Daher kann diese Frage auch unter SELinux nicht allgemein beantwortet werden.

(1) - Wenn ein System keine bestimmte Funktion bereitstellt, z. B. keine Echtzeit-Kernelfunktionalität, halte ich die Aussage "root hat keinen Zugriff auf diese Funktionalität" für falsch, da diese Aussage auf a beruht falsche Annahme (nämlich, dass die gegebene Funktion jedem auf diesem System zur Verfügung steht)

Einerseits gibt es Dinge, die kein Benutzer tun kann, wie z

• Hardlinking von Verzeichnissen (aufgrund von Dateisystembeschränkungen)
• Beschreiben einer bereits gebrannten CD-ROM (wegen Physik)

Aber das sind keine Privilegien, weil sie nicht gewährt werden können, sie sind einfach für niemanden möglich.

Dann gibt es Einschränkungen für das gesamte System oder Teile davon, die ein- oder ausgeschaltet werden können.
Unter OS X gibt es beispielsweise die Option, die Ausführung von Code nur zuzulassen, wenn er von Apple signiert wurde.

Ich halte dies auch nicht für ein Privileg, da es kein Benutzer haben kann, wenn der Superuser es nicht kann. Sie können es nur global deaktivieren.

Bearbeiten:
Ihre Vorstellung von einer Datei ohne das ausführbare Bit fällt ebenfalls in diese Kategorie, da dies buchstäblich niemand kann und niemand diese Berechtigung erhalten kann.
Und selbst wenn Sie einem anderen Benutzer oder einer anderen Gruppe die Berechtigung erteilen, diese Datei auszuführen, jedoch nicht root oder eine Benutzergruppe, in der root sich befindet, kann root diese Datei weiterhin ausführen (getestet auf OS X 10.10-, 10.11- und Ubuntu 15.04-Servern).

Abgesehen von diesen Fällen gibt es kaum etwas, was root nicht tun kann.
Es gibt jedoch einen Kernelmodus (im Gegensatz zum Benutzermodus).

Soweit ich weiß, laufen auf einem vernünftigen System nur der Kernel, die Kernel-Erweiterungen und die Treiber im Kernel-Modus, und alles andere (einschließlich der Shell, von der aus Sie sich als root anmelden) läuft im Benutzermodus.
Man könnte daher argumentieren, dass "root sein nicht genug ist". Auf den meisten Systemen ist der Root-Benutzer jedoch in der Lage, Kernel-Module zu laden, die wiederum im Kernel-Modus ausgeführt werden. Auf diese Weise kann der Root-Benutzer Code im Kernel-Modus ausführen.

Es gibt jedoch Systeme (wie iOS), bei denen dies nicht (willkürlich) möglich ist, zumindest nicht ohne die Ausnutzung von Sicherheitsvorkehrungen. Dies ist hauptsächlich auf eine erhöhte Sicherheit zurückzuführen, wie die Durchsetzung von Codesignaturen. In den Prozessoren von iDevices
sind beispielsweise AES-Verschlüsselungsschlüssel integriert, auf die nur im Kernel-Modus zugegriffen werden kann. Kernel-Module könnten auf diese zugreifen, aber der Code in diesen Kernel-Modulen müsste auch von Apple signiert werden, damit der Kernel sie akzeptiert.

Unter OS X gibt es seit Version 10.11 (El Capitan) auch einen sogenannten "rootless mode" (obwohl der Name irreführend ist, weil root immer noch existiert), der Roots bestimmte Dinge verbietet, die Installer noch ausführen können.
Zitat aus dieser ausgezeichneten Antwort auf AskDifferent :

Hier ist, was es einschränkt, auch von root:

• Sie können nichts in / System, / bin, / sbin oder / usr ändern (außer / usr / local); oder eine der integrierten Apps und Dienstprogramme. Nur das Installationsprogramm und das Software-Update können diese Bereiche ändern, und dies auch nur, wenn von Apple signierte Pakete installiert werden.

Die "Systemkernausführung", die Sie erwähnen, ist gut unter rootKontrolle, z. B. über ladbare Kernelmodule. Dies setzt natürlich voraus, dass das Laden von Kernelmodulen vom Kernel unterstützt wird und niemand Aktionen ausführen kann, die selbst nicht durchführbar sind root.

Gleiches gilt für Systemprozesse. rootEs ist jedoch nicht möglich, einen im Kernel-Modus ausgeführten Prozess anzuhalten, ohne die Integrität des Kernels zu beeinträchtigen. Daher ist es einfach nicht möglich, einen solchen Prozess sofort anzuhalten. Beachten Sie, dass rootes nicht verweigert wird, diese Prozesse zu beenden. Das Beenden selbst hat einfach keine Auswirkung.

Endlich der echte Modus: Der Linux-Kernel hat keine Unterstützung dafür, also kann auch hier niemand das Unmögliche tun, nicht einmal root.

@Siguza erwähnte die Ausführung von Dateien ohne xErlaubnis, was für den rootBenutzer durchaus möglich ist :

/lib/ld-linux.so.2 /path/to/executable

Ein Beispiel könnte das Ändern einer unveränderlichen Datei sein: Sie können ein Dateiattribut festlegen, imit chattrdem die Datei auch für root unveränderlich wird. Beispielsweise:

# whoami
root
# touch god
# chattr +i god
# rm god
rm: cannot remove ‘god’: Operation not permitted
# touch god
touch: cannot touch ‘god’: Permission denied

Beachten Sie, dass die Datei in der ls -lAusgabe als normale beschreibbare Datei angezeigt wird :

# ls -l god
-rw-r--r-- 1 root root 0 Oct 26 19:27 god

Um das iAttribut zu sehen, müssen Sie Folgendes verwenden lsattr:

# lsattr god
----i----------- god

Die Handbuchseite von chattr gibt Folgendes zu dem iAttribut an:

Eine Datei mit dem Attribut "i" kann nicht geändert werden: Sie kann nicht gelöscht oder umbenannt werden, es kann kein Link zu dieser Datei erstellt werden und es können keine Daten in die Datei geschrieben werden. Nur der Superuser oder ein Prozess mit der Funktion CAP_LINUX_IMMUTABLE kann dieses Attribut festlegen oder löschen.

Root kann die Unveränderlichkeit jedoch leicht rückgängig machen:

# chattr -i god
# rm -v god
removed ‘god’

Unter FreeBSD können Sie nicht gmirroreinmal als root eine bereits gemountete Partition verwenden:

gmirror label -v -b prefer gm0s1 ad4s1
gmirror: Auf ad4s1 können keine Metadaten gespeichert werden: Vorgang nicht zulässig.

Sie müssen ein sysctl( kern.geom.debugflags=16) setzen, um dies zu tun.

rootist ein privilegierter Benutzer, aber diese Rechte werden vom Kernel vergeben. Der Kernel hat also mehr Privilegien als root.

Die Annahme, dass der Root-Benutzer selbst für die Zusammenarbeit zuständig ist, rootkann den Zugriff auf FUSE-Bereitstellungen (mit den Optionen allow_otheroder allow_root) verhindern. Dies liegt jedoch daran, dass FUSE so konzipiert wurde. Da sich FUSE auf einer virtuellen Ebene befindet, kann es jeden Fehler auf der Grundlage der Logik zurückgeben, im Gegensatz zu allgemeinen Blockgerätemodulen, die versuchen, so transparent und dünn wie möglich zu sein und Berechtigungen an eine andere Ebene zu delegieren.

Dies hindert den Root-Benutzer nicht daran, die Option zu deaktivieren oder das FUSE-Modul durch ein Modul zu ersetzen, das die Option unbemerkt verwirft, es sei denn, Sie machen das Dateisystem schreibgeschützt. Dies führt jedoch nur zu einer Situation "Wer beobachtet die Wächter": Wie können Sie bestätigen, dass das System nicht lügt? Ihre Shell befindet sich möglicherweise sogar in einer Chroot, die Ihnen ein legitimes FUSE-Modul zeigt, während der Kernel tatsächlich eine böswillige Version davon ausführt.

Ich würde sagen, dass die Unfähigkeit, nicht ausführbare Dateien auszuführen, eine triviale Einschränkung ist, da sie von den Dateiberechtigungen abhängt. (Es ist möglich, dies mit /lib64/ld-linux-x86-64.so.2 für eine nicht ausführbare Datei zu umgehen, jedoch nicht für eine Datei, die sich in einem nicht ausführbaren Mount befindet.)

Es gibt auch das Problem der obligatorischen Dateisperren, die die Dateibearbeitung verhindern, wenn eine Datei gerade von einem Prozess verwendet wird, obwohl der Superuser den Prozess abbrechen kann.

An einem Punkt konnte der Superuser ein Gerät nicht aushängen, während das Gerät ausgelastet war, aber dies kann jetzt mit einem Lazy-Umount durchgeführt werden.

Andere Einschränkungen sind:

Unveränderliche Dateien können nicht geändert und nur an Nur-Anhängen-Dateien angehängt werden. (Unter Linux kann der Super-User die unveränderlichen Dateien entfernen und nur Flags auf jeder Ausführungsebene anhängen, ohne jedoch den Zweck dieser Dateien zu beeinträchtigen.)

Es ist nicht möglich, in ein schreibgeschütztes Mount zu schreiben oder auf einem nicht ausführbaren Mount etwas auszuführen

kann ein nicht bindbares Reittier nicht binden

Ein Dateisystem kann nicht erneut als Lese- / Schreibzugriff bereitgestellt werden, wenn sein Blockgerät schreibgeschützt ist

Auf einem Sicherungs-Mount, der einem anderen Benutzer gehört, kann nichts angegeben werden, es sei denn, es wurde allow-other oder allow-root gemountet

kann nicht SELinux-Einstellungen verletzen

Absichtliche Einschränkungen des Systems selbst, die sich auf root auswirken:

kann die C-Zeit einer Datei nicht direkt festlegen (oder die Geburtszeit, falls diese jemals implementiert wurde)

Kennwörter können nicht als Nur-Text angezeigt werden