Wir haben ein kleines Problem auf einem Server. Wir möchten, dass einige Benutzer z. B. sudoroot werden können, jedoch mit der Einschränkung, dass der Benutzer das root-Passwort nicht ändern kann. Dies ist eine Garantie dafür, dass wir uns weiterhin bei diesem Server anmelden und root werden können, unabhängig davon, was die anderen Benutzer tun werden.

Ist das möglich?

Wir möchten, dass einige Benutzer in der Lage sind, zB sudoroot zu werden,

Nun, das ist das Problem, das sudo lösen soll, sodass dieser Teil einfach genug ist.

aber mit der Einschränkung, dass der Benutzer das root-Passwort nicht ändern kann.

Sie können, wie SHW in einem Kommentar hervorhob, sudo so konfigurieren, dass nur bestimmte Aktionen von bestimmten Benutzern als Root ausgeführt werden. Das heißt, können Sie erlauben user1 zu tun sudo services apache2 restart, erlauben user2 zu tun , sudo rebootaber nichts anderes, während man das gemietete-as-System-Administrator user3zu tun sudo -i. Es gibt Anleitungen, wie man sudo so einrichtet, oder Sie können hier suchen (oder fragen). Das ist ein lösbares Problem.

Ein Benutzer, dem beispielsweise die Berechtigung zum sudo -ioder sudoin eine Shell gewährt wurde sudo bash, kann jedoch alles tun. Das liegt daran, dass sudo selbst zu dem Zeitpunkt, zu dem sudo die Shell startet, nicht mehr im Bild ist. Es bietet den Sicherheitskontext eines anderen Benutzers (meistens root), hat jedoch keinen Einfluss darauf, was die ausgeführte Anwendung tut. Wenn diese Anwendung passwd rootgestartet wird, kann sudo nichts dagegen tun. Beachten Sie, dass dies auch über andere Anwendungen möglich ist. Beispielsweise bieten viele der fortgeschritteneren Editoren Funktionen zum Ausführen eines Befehls über die Shell, eine Shell, die mit der effektiven UID dieses Editorprozesses (d. h. root) ausgeführt wird.

Dies ist eine Garantie dafür, dass wir uns weiterhin bei diesem Server anmelden und root werden können, unabhängig davon, was die anderen Benutzer tun werden.

Es tut uns leid; Wenn Sie wirklich "sicherstellen, dass wir in der Lage sind, uns anzumelden und das System zu verwenden, unabhängig davon, was jemand mit Root-Zugriff tut", können Sie dies (in jeder Hinsicht) nicht tun. Ein kurzes "sudo rm / etc / passwd" oder "sudo chmod -x / bin / bash" (oder was auch immer Shell Root verwendet) und Sie sind sowieso ziemlich abgespritzt. "Ziemlich abgespritzt" bedeutet "Sie müssen von einem Backup wiederherstellen und hoffen, dass sie nichts Schlimmeres als einen Fingerabdruck getan haben". Sie können einige Schritte unternehmen, um das Risiko eines versehentlichen Unfalls, der zu einem unbrauchbaren System führt, zu verringern. Sie können jedoch nicht verhindern, dass böswillige Handlungen schwerwiegende Probleme verursachen, bis hin zu dem Punkt, dass das System von Grund auf oder zumindest von Grund auf neu erstellt werden muss gute backups.

Indem Sie einem Benutzer uneingeschränkten Root-Zugriff auf ein System gewähren, vertrauen Sie darauf, dass dieser Benutzer (einschließlich der Software, die er möglicherweise ausführt, auch wenn es sich um etwas Alltägliches wie ls handelt) keine böswilligen Absichten hat und nicht versehentlich Unfug treibt. Das liegt in der Natur des Root-Zugriffs.

Eingeschränkter Root-Zugriff durch z. B. sudo ist ein bisschen besser, aber Sie müssen trotzdem darauf achten, keine Angriffsvektoren zu öffnen. Und mit Root-Zugriff gibt es viele mögliche Angriffsmethoden für Privilegien-Eskalationsangriffe.

Wenn Sie ihnen nicht vertrauen können, welche Zugriffsberechtigung root hat, müssen Sie entweder eine stark eingeschränkte sudo-Konfiguration verwenden oder dem betreffenden Benutzer auf keinen Fall den root-Zugriff gewähren, sei es sudo oder auf andere Weise.

Das ist praktisch unmöglich. Erstens, wenn Sie ihnen die Macht einräumen , Wurzel zu werden , können Sie nichts tun, um sie daran zu hindern, irgendetwas zu tun. In Ihrem Anwendungsfall sudosollten Sie Ihren Benutzern einige Root-Berechtigungen gewähren, während Sie andere einschränken, ohne zuzulassen, dass sie Root werden .

In Ihrem Szenario, müssten Sie den Zugriff auf die beschränken suund passwdBefehle und offenen Zugang zu so ziemlich alles andere. Das Problem ist, dass Sie nichts tun können, um Ihre Benutzer daran zu hindern, das Root-Passwort direkt zu bearbeiten /etc/shadow(oder /etc/sudoerszu verwenden) und es zu ersetzen, um root zu hijacken. Und dies ist nur das einfachste mögliche "Angriffsszenario". Sudoer mit uneingeschränkter Leistung, mit Ausnahme von ein oder zwei Befehlen, können die Einschränkungen umgehen, um den vollständigen Root-Zugriff zu entführen.

Die einzige Lösung, die SHW in den Kommentaren vorschlägt, besteht sudodarin, Ihren Benutzern stattdessen Zugriff auf einen eingeschränkten Befehlssatz zu gewähren.

Aktualisieren

Möglicherweise gibt es eine Möglichkeit, dies zu erreichen, wenn Sie Kerberos-Tickets zur Authentifizierung verwenden. Lesen Sie dieses Dokument , in dem die Verwendung der .k5loginDatei erläutert wird .

Ich zitiere die relevanten Teile:

Angenommen, die Benutzerin alice hatte eine .k5login-Datei in ihrem Ausgangsverzeichnis, die die folgende Zeile enthält: Auf
bob@FOOBAR.ORG
diese Weise kann bob mithilfe von Kerberos-Tickets von bob mithilfe von Kerberos-Netzwerkanwendungen wie ssh (1) auf das Konto von alice zugreifen.
...
Beachten Sie, dass Bob, da er die Kerberos-Tickets für seinen eigenen Auftraggeber aufbewahrt, bob@FOOBAR.ORGkeine der Berechtigungen hat, die Alice-Tickets erfordern, z. B. Root-Zugriff auf Hosts der Site oder die Möglichkeit, das Passwort von Alice zu ändern.

Ich könnte mich jedoch irren. Ich stöbere immer noch in der Dokumentation und muss Kerberos noch selbst ausprobieren.

Ich gehe davon aus, dass Sie sicherstellen möchten, dass Sie einen "Notfall-Administrator" -Zugriff haben, auch wenn Ihr tatsächlicher Administrator Probleme hat (ansonsten vertrauen Sie dem Hauptadministrator voll und ganz).

Ein populärer Ansatz (obwohl sehr hackisch) ist es, einen zweiten Benutzer mit einemuid=0 gemeinsamen Namen toor(root backwards) zu haben. Es hat ein anderes Kennwort und kann als Sicherungszugriff dienen. Zum Hinzufügen müssen Sie wahrscheinlich die Zeilen bearbeiten /etc/passwdund /etc/shadow(kopieren root).

Es ist alles andere als ausfallsicher, aber wenn Sie sich nur davor schützen müssen, dass der "Hauptadministrator" das Passwort ohne Vorankündigung ändert, funktioniert es. Es ist trivial zu deaktivieren, indem Sie das toorKonto entfernen ; Der einzige Vorteil besteht also darin, ein separates Passwort zu haben.

Alternativ können Sie alternative Authentifizierungsmechanismen untersuchen, z. B. sshSchlüssel libnss-extrausers, LDAP usw.

Beachten Sie, dass der Administrator immer noch schlecht vermasseln kann. Zum Beispiel durch Blockieren der Firewall.

Wenn Sie ein sehr sicheres System haben möchten, ziehen Sie die Verwendung von SELinux in Betracht, bei dem der Unix-Benutzer (z. B. root) auch eine Rolle mitbringt, die viel detaillierter sein kann. Möglicherweise möchten Sie Ihrem Administrator root-Zugriff gewähren, jedoch nur eine eingeschränkte Rolle (z. B. um nur Apache zu verwalten). Dies erfordert jedoch einen erheblichen Aufwand, um die Richtlinie korrekt zu konfigurieren.

Die Essenz von root besteht darin, das System uneingeschränkt zu beherrschen. Sie könnten es mit SELinux optimieren (es gab früher eine Demo-Site, auf der sich jeder als Root anmelden konnte, aber die Leistung wurde durch das Zugriffssystem beeinträchtigt), aber das ist nicht der Punkt. Der Punkt ist, dass dies die falsche Lösung für Ihr Problem ist.

Nun, Sie haben nicht gesagt, was Ihr Problem ist, aber wenn Sie diesen Benutzern nicht vertrauen, dass sie das Root-Passwort nicht kennen, haben sie nichts damit zu tun, Root zu sein. Wenn sie den Webserver oder verschiedene Hardwaregeräte oder das Warp-Laufwerk oder was auch immer verwalten müssen, richten Sie eine Lösung dafür ein. Erstellen Sie eine leistungsstarke Gruppe, geben Sie ihr den erforderlichen Zugriff und fügen Sie sie hinzu. Wenn sie nur Root-Systemaufrufe ausführen müssen, schreiben Sie einige setuid-Programme.

Natürlich könnte ein Benutzer mit dieser Art von Zugriff (und ein bisschen Wissen) das System leicht hacken, aber zumindest arbeiten Sie mit dem Sicherheitsmodell des Betriebssystems, nicht dagegen.

PS. Es gibt viele Möglichkeiten, den Root-Zugriff für sich selbst ohne das Kennwort zu arrangieren. Zum einen, wenn Sie /etc/sudoers(ohne Einschränkungen) in sind, brauchen Sie nur Ihr eigenes Passwort, um root zu werden, zB mit sudo bash. Aber Sie sollten einfach nicht dorthin müssen.

Zumindest theoretisch ist es wahrscheinlich möglich, dies mit SELinux zu tun . Auf diese Weise können Sie präzisere Regeln festlegen, was ein Benutzer oder Prozess tun darf oder nicht. Selbst mit SELinux kann es schwierig sein, es einem Benutzer unmöglich zu machen, das root-Passwort zu ändern, aber dennoch in der Lage zu sein, alles zu tun, was er tun muss.

Es hängt wirklich davon ab, was der Benutzer, der das root-Passwort nicht ändern darf, tatsächlich tun muss. Es wäre wahrscheinlich einfacher und sicherer, nur herauszufinden, was das ist, und diese Berechtigungen speziell mit sudo zu erteilen.

Vielleicht sollten Sie in Betracht ziehen, den Benutzern Root-Zugriff auf eine virtuelle Maschine oder einen LXC-Container zu gewähren. Auf diese Weise erhalten sie vollständigen Root-Zugriff auf ein System, ohne dass Sie sich beim Host anmelden oder administrative Maßnahmen ergreifen können.

Ich weiß nicht, dass es praktisch machbar sein wird, aber hier ist ein dreckiger Hack:

1. Schreiben Sie ein Wrapper-Skript / Programm, das die /etc/passwdDatei an einen anderen Ort kopiert , bevor Sie actual aufrufensudo
2. Erlauben Sie dem normalen Benutzer die Verwendung sudo
3. Stellen Sie die /etc/passwdDatei wieder her, sobald er seine Aufgabe beendet hat oder aus sudo herausgekommen ist

Ich weiß, es gibt viele Plus-Minus-Faktoren, die Sie berücksichtigen müssen, um dies zu erreichen. Immerhin ist es ein schmutziger Hack

Die Aussage, sudodie nur zur Vergabe von root dient und danach keinen Schutz bietet, ist offensichtlich falsch.

Mit können Sie visudodie sudoers-Datei ändern. Hier ist eine Beispielzeile:

redsandro ALL=(ALL:ALL) NOPASSWD:/path/to/command

• redsandroist der Benutzername, dem wir die Erlaubnis geben. Setzen Sie ein %an die Front, damit es für eine Gruppe gilt.
• ALList ein Name für diese Regel. Sudoer können viel mehr als nur globale Berechtigungen erteilen. Hier wird es allerdings kompliziert.
• = braucht keine Erklärung
• ALL:ALLliest als (who_to_run_it_as: what_group_to_run_it_as). Auf diese Weise können Sie die Ausführung eines Befehls zulassen, jedoch nur im Kontext eines bestimmten Benutzers oder einer bestimmten Gruppe.
• NOPASSWD: weist es an, die Passwortabfrage auszuschalten.
• /path/to/command Ermöglicht die Angabe spezifischer Befehle path_to_commmand, another_command

Die Sache, an die man sich erinnern sollte, ist, dass die sudomeisten Heimanwender die Root-Rechte verwenden. Sie können den Zugriff auf bestimmte Befehle jedoch sehr viel detaillierter steuern.

Verweise

• von meiner anderen Antwort hier

(Ich kenne ubuntu nicht, aber es sollte Fedora / Red-Hat ähneln.)
Das einzige, was ich mir vorstellen kann, um den Zugriff auf das Ändern des root-Passworts einzuschränken, ist nicht den vollständigen root-Zugriff, möglicherweise mit sudo, oder mit SElinux, um den Zugriff einzuschränken an die Passwortdatei ... aber ich würde weder mit vielem Zugriff vertrauen, da root im Allgemeinen uneingeschränkten Zugriff hat und SElinux aktualisieren oder die Passwortdatei umbenennen oder ein vorab vorbereitetes Programm ausführen könnte, um das Passwort zu ändern.

Wenn Sie ihnen nicht genug vertrauen, um das Kennwort nicht zu ändern, sollten Sie ihnen wahrscheinlich keinen Root-Zugriff gewähren. Ansonsten würden Sie wohl versuchen, Unfälle zu vermeiden.

Wenn Sie nur versuchen, Ihren Zugriff auf root zu schützen, richten Sie ein Programm ein, das das root-Passwort wiederherstellen kann. Selbst wenn es geändert wird, kann es mit minimalem Zugriff wiederhergestellt werden. (sudo macht sich von alleine gut)

Ihre Anforderung ist:

Wir haben ein kleines Problem auf einem Server, [...] eine Garantie, dass wir uns immer noch auf diesem Server anmelden und root werden können, unabhängig davon, was die anderen Benutzer tun werden.

Aus Ihrer Frage geht hervor, dass Sie nicht mit zufälligen böswilligen Benutzern konfrontiert sind, die beabsichtigen, Ihr System zu zerstören, sondern mit halb vertrauenswürdigen Benutzern, die hin und wieder Unheil anrichten können (Studenten vielleicht?). Meine Vorschläge befassen sich mit dieser Situation, nicht mit einem vollständigen Angriff böswilliger Benutzer.

1. Führen Sie den Server in einer virtuellen Umgebung aus. Sie können das Dateisystem des Servers mounten und geänderte Dateien durch als funktionierend bekannte Versionen ersetzen. Abhängig von dem möglichen Schaden, den Sie erwarten, können Sie einen Schnappschuss aller kritischen Verzeichnisse (/ bin, / sbin, / etc, / usr, / var usw.) erstellen und den Schnappschuss erweitern, um beschädigte Dateien zu überschreiben, während der Rest des Verzeichnisses erhalten bleibt System intakt.

2. Führen Sie das System schreibgeschützt aus, z. B. von einer DVD-R. Wenn Sie bis zum nächsten Neustart damit leben können, dass die meisten Teile des Systems statisch sind, ist dies eine gute Option. Sie können auch einen schreibgeschützten Sicherungsspeicher mit einer virtuellen Umgebung verwenden oder das Basissystem über das Netzwerk laden, wodurch Änderungen zwischen Neustarts viel einfacher sind als das Beschreiben einer neuen DVD-R.

3. Kernel-Module. Die Linux Security Modules (LSM) des Kernels bilden die Grundlage für die Erstellung sicherer Module. LSM wird von SELinux verwendet, aber auch von einigen weniger bekannten und einfacheren Systemen wie Smack, TOMOYO und AppArmor. Dieser Artikel bietet einen guten Überblick über die Optionen. Es besteht die Möglichkeit, dass eine dieser Optionen direkt konfiguriert werden kann, um den Schreibzugriff auf / etc / passwd, / etc / shadow oder andere Dateien, die Sie möchten, auch von root zu verhindern.

4. Die gleiche Idee wie Nummer 1, aber wenn sich der Server nicht in einer virtuellen Umgebung befindet. Sie könnten den Server in ein schreibgeschütztes Betriebssystem wie eine Live-CD laden lassen, das das Dateisystem des Servers automatisch mounten und das Basissystem bei jedem Start mit als funktionierend bekannten Kopien überschreiben würde. Das schreibgeschützte Betriebssystem würde dann in das Hauptbetriebssystem booten.

5. Angenommen, es handelt sich um halb vertrauenswürdige Benutzer, die gegenüber einem Vorgesetzten (Lehrer / Chef) rechenschaftspflichtig sind, lautet die beste Antwort möglicherweise Linux Audit . Auf diese Weise wissen Sie, welche sicherheitsrelevanten Maßnahmen ergriffen wurden und wer sie ergriffen hat (Sie wissen, wer sie ergriffen hat, denn selbst wenn alle Benutzer das Root-Konto gemeinsam nutzen, werden sie zuerst von ihrem Benutzerkonto abgerufen). Tatsächlich sind Sie möglicherweise sogar in der Lage, das Überwachungsprotokoll in Echtzeit zu analysieren und beschädigte Dateien zu ersetzen. / etc / shadow überschrieben? Kein Problem, lassen Sie den Überwachungsserver sofort durch eine als funktionierend bekannte Version ersetzen.

Weitere Technologien, die Sie möglicherweise basierend auf Ihren Anforderungen untersuchen möchten:

• Linux-Integritätsmessungsarchitektur / Erweitertes Überprüfungsmodul (IMA / EVM) und
• Vertrauenswürdige Plattformmodule (TPM).

Um die anderen Antworten zu ergänzen, gehe ich davon aus, dass Sie die Kontrolle über root in einer seltenen Situation verlieren und in diesen Fällen ein Neustart des Servers zulässig ist. (Wenn Sie der Meinung sind, dass der Computer kompromittiert wurde, sollten Sie ihn trotzdem offline schalten.)

Der große Vorteil dabei ist, dass nichts zu konfigurieren ist. Ihre Frage lautet: " Ich habe das root-Passwort vergessen, wie komme ich zurück? " Die Antwort darauf lautet: Neustart und Auswahl des Einzelbenutzermodus, wenn der Computer gestartet wird. Dadurch erhalten Sie eine Root-Shell, ohne das Kennwort kennen zu müssen. An diesem Punkt können Sie ein neues Passwort festlegen. (Sowie gehen und Schäden reparieren ...)

Wenn Sie Ihren Server in eine VM (z. B. VirtualBox ) klonen , können Sie den Benutzern uneingeschränkten Root-Zugriff gewähren und dennoch sicherstellen, dass Sie immer direkten Zugriff auf die Partitionen des Gastbetriebssystems haben und somit die endgültige Kontrolle über /etc/passwdund behalten Ähnliches, da Sie root auf dem Host-System haben werden.

Natürlich ist das Gewähren eines uneingeschränkten Root-Zugriffs möglicherweise immer noch nicht die richtige Lösung: Wenn Datensicherheit überhaupt ein Problem ist oder in Ihrer Verantwortung liegt, können Sie den Root-Zugriff nicht verweigern.

Die Anforderung ist technisch nicht möglich. Wie bereits eloquent kommentiert, bedeutet das Gewähren unbegrenzter oder noch eingeschränkter sudoRechte für einen Benutzer, dass Sie diesem Benutzer vertrauen . Jemand, der böse Absichten und genügend technische Fähigkeiten und Ausdauer hat, kann alle Hindernisse überwinden, die vorhanden sind.

Unter der Annahme, dass Sie darauf vertrauen können, dass Ihre Benutzer nicht in böser Absicht handeln, können Sie die Einschränkung der Kennwortänderung zu einer Angelegenheit der Richtlinie machen . Sie können einen Wrapper für das passwdProgramm erstellen , der Sie daran erinnert, dass Sie das root-Passwort nicht ändern sollen. Dies setzt voraus, dass die Ursache des Problems darin besteht, dass die Benutzer, die das Root-Passwort ändern, dies aufgrund eines Missverständnisses tun (zum Beispiel, wenn sie glauben, dass sie ihr eigenes Passwort ändern, nachdem sie dies getan haben sudo bash).

Wenn unter bestimmten (seltenen) Umständen kein vollständiges Vertrauen möglich ist und es nicht möglich ist, den sudoZugang zu angemessenen, aber einigermaßen sicheren Datenblöcken zu unterbrechen, können organisatorische Sanktionen gegen Kennwortänderungen (oder andere festgelegte Formen von Systemmanipulationen) ergriffen werden Überwachen kritischer Ressourcen, sodass es nicht einfach ist , unentdeckt an den festgelegten Richtlinien vorbeizukommen. Seien Sie öffentlich und transparent über die Verwendungsregeln und die Überwachung.

Der Aspekt der Überwachung und Ermittlung ist ein schweres technisches Problem, das von einer anderen Frage profitiert, falls Sie diesen Weg beschreiten. Es scheint mir, wir müssten

1. Erkennen Sie, wenn ein Benutzer die Identität in root ändert, und verfolgen Sie alle erstellten Prozesse.
2. Protokollieren Sie die Prozesserstellungen von nun an, um zu sehen, wer der ursprüngliche Benutzer ist, der für jeden Prozess verantwortlich ist, und verwenden Sie einen Remote-Host, auf dem die halb vertrauenswürdigen Benutzer keinen Zugriff zum Senden der Protokolle haben.
3. Verwenden Sie eine Art Systemablaufverfolgung, um das Geschehen zu protokollieren und später herauszufinden, wer hinter der Richtlinienverletzung steckt.

Wir müssten zumindest das Öffnen eines anderen als des sicheren Satzes von Dateien zum Schreiben, Erstellen von Prozessen exec()und natürlich für jeden Versuch, das Netzwerk zu ändern, protokollieren.

Die Implementierung könnte durch eine modifizierte libc oder (viel bessere) Systemaufrufverfolgung erfolgen.

Natürlich ist es nicht möglich, eine solche Nachverfolgung und Protokollierung zu 100% korrekt durchzuführen, sie ist nicht einfach zu implementieren und erfordert zusätzliche Betriebsmittel. Dies würde die Passwortänderung oder andere unerwünschte Systemmanipulationen nicht stoppen , aber es würde (wahrscheinlicher) möglich machen, den schuldigen Benutzer zu finden oder zumindest die Illusion zu erzeugen, dass es eine Überwachung gibt, und es für einige böse gesinnte Benutzer weniger einladend machen (aber Einige problemliebende Hacker, die die grundsätzliche Sinnlosigkeit der technischen Maßnahmen erkennen, fühlen sich möglicherweise ermutigt, die Herausforderung anzunehmen und zu versuchen, das System nur zum Spaß zu umgehen.

Die ursprünglich formulierte Frage ist unbrauchbar. Es sieht so aus, als ob das Hauptziel darin besteht, "immer noch angemeldet zu sein", also über einen Notruf zu sprechen, der sicher funktioniert, auch wenn einer anderen Person Root-Zugriff gewährt wird. Cheers to Anony-Mousse, der es zuerst explizit notiert hat.

Das Problem ist: Wenn der Besitzer physischen Zugriff auf die Box hat, kann er auf einfache Weise den logischen Zugriff auf das System wiederherstellen (vorausgesetzt, es lebt noch :). Wenn dies nicht der Fall ist - wenn das root-Passwort nicht beibehalten wird, kann es nicht von zB sshd down oder einem fehlerhaften Netzwerk-Setup wiederhergestellt werden. Daher ist das System trotzdem nicht erreichbar.

Das Thema, wie das System vor Beschädigung durch eine Person mit Administratorrechten geschützt werden kann, scheint zu umfangreich für das SE-Fragenformat zu sein.

Wenn es sich um eine Remote-Notruflösung handelt, ist IPMI (glaube ich) der beste Weg, wenn es verfügbar ist. Der Systembesitzer kann jederzeit ein virtuelles Laufwerk anhängen, von diesem booten und mit der Systemwiederherstellung fortfahren.

Wenn IPMI nicht verfügbar ist, kann jede geeignete Virtualisierungstechnologie, wie oben bereits vorgeschlagen, umgangen werden.

Sie können den Zugriff auf sudo in Ihrer /etc/sudoersDatei einschränken

Um die Syntax von / etc / sudoers vollständig zu erklären, werden wir eine Beispielregel verwenden und jede Spalte aufschlüsseln:

jorge  ALL=(root) /usr/bin/find, /bin/rm

Die erste Spalte definiert, für welchen Benutzer oder welche Gruppe diese Sudo-Regel gilt. In diesem Fall ist es der Benutzer jorge. Wenn dem Wort in dieser Spalte ein% -Symbol vorangestellt ist, wird dieser Wert als Gruppe anstelle eines Benutzers bezeichnet, da ein System Benutzer und Gruppen mit demselben Namen haben kann.

Der zweite Wert (ALL) definiert, für welche Hosts diese Sudo-Regel gilt. Diese Spalte ist am nützlichsten, wenn Sie eine sudo-Umgebung auf mehreren Systemen bereitstellen. Bei einem Desktop-Ubuntu-System oder einem System, bei dem Sie die sudo-Rollen nicht auf mehreren Systemen bereitstellen möchten, können Sie diesen Wert auf ALL belassen. Dies ist ein Platzhalter, der allen Hosts entspricht.

Der dritte Wert steht in Klammern und definiert, unter welchem ​​Benutzer oder welchen Benutzern der Benutzer in der ersten Spalte einen Befehl ausführen kann. Dieser Wert ist auf root gesetzt, was bedeutet, dass jorge die in der letzten Spalte angegebenen Befehle als root-Benutzer ausführen darf. Dieser Wert kann auch auf den Platzhalter ALL gesetzt werden, mit dem Jorge die Befehle als jeder Benutzer auf dem System ausführen kann.

Der letzte Wert (/ usr / bin / find, / bin / rm) ist eine durch Kommas getrennte Liste von Befehlen, die der Benutzer in der ersten Spalte als Benutzer in der dritten Spalte ausführen kann. In diesem Fall erlauben wir Jorge, find und rm als root auszuführen. Dieser Wert kann auch auf den Platzhalter ALL gesetzt werden, mit dem Jorge alle Befehle auf dem System als root ausführen kann.

In diesem Sinne können Sie X-Befehle kommagetrennt zulassen. Solange Sie dies nicht ergänzen passwd, sollten Sie in Ordnung sein

Es gibt keine 1/2-Wurzel :) Sobald Sie Root-Rechte vergeben, können sie tun, was sie wollen. Alternativ können Sie sudo verwenden, um eine eingeschränkte Bash- Shell oder den rbash ohne Root-Rechte auszuführen.

Wenn Sie einen ausfallsicheren Mechanismus für die Anmeldung am Server als Root haben möchten, können Sie entweder einen anderen Benutzer mit uid=0oder einen einfachen Cron erstellen, der das Root-Passwort regelmäßig zurücksetzt.

Versuchen Sie, eine Radgruppe hinzuzufügen, anstatt sudo zu verwenden. Mit sudo kann ein Benutzer so ausführen, als ob er root wäre, was bedeutet, dass es sich nicht von der Ausführung unterscheidet:

su -

wurzel werden. Die Root-UID = 0; die Rad-UID = 10. Die Leute benutzen die Namen, aber das Betriebssystem benutzt die UID. Bestimmte Befehle können nicht von einem Mitglied der Radgruppe ausgeführt werden. (Wenn Sie Wheel verwenden, machen Sie nicht den Fehler, Root als Wheel-Gruppenmitglied hinzuzufügen.) Werfen Sie einen Blick in die Red Hat-Dokumentation, wenn Sie nicht wissen, um welches Rad es sich handelt.

Eine andere Möglichkeit ist die Verwendung eines SSH-Schlüssels anstelle eines Passworts. Vorausgesetzt, Sie können sicher sein, dass die Benutzer, die sudo verwenden, ihre öffentlichen Schlüssel nicht zur Datei ~ / .ssh / authorizedkeys hinzufügen, kann dies zu Problemen beim Ändern des Root-Passworts führen, da das Root-Passwort effektiv ignoriert wird.

Wenn Sie es vorziehen, das Vertrauen dieser Benutzer zu erweitern (um keinen eigenen öffentlichen Schlüssel hinzuzufügen), versuchen Sie, erweiterte Dateiattribute und das Bit "Unveränderlich" zu verwenden. Setzen Sie nach dem Erstellen Ihrer ~ / .ssh / authorizedkeys-Datei und nach dem Konfigurieren von / etc / ssh / sshd_config und / etc / ssh / ssh_config das unveränderliche Bit. Klar, es gibt auch Möglichkeiten, damit umzugehen - nichts ist perfekt.

Insider sind in jedem System das höchste Risiko. Die Person, die die Show leitet, steht ganz oben auf dem Stapel. Ein verwandter Gedanke betrifft Verträge. Anwälte werden Ihnen sagen: "Machen Sie niemals Geschäfte mit jemandem, mit dem Sie einen Vertrag abschließen müssen". Der gesunde Menschenverstand sagt uns: "Machen Sie niemals Geschäfte ohne Vertrag". Wenn Sie jemanden finden, dem Sie vertrauen, schreiben Sie den Vertrag auf der Grundlage der Bedürfnisse des anderen.

Alle eingereichten Antworten, einschließlich meiner, können den physischen Zugriff nicht behandeln. Wer es hat, hat Kontrolle. Wenn Sie es nicht sind, gibt es wahrscheinlich eine Möglichkeit, die Person, die physisch auf das Gerät zugreift, dazu zu bringen, falls jemand eine Möglichkeit findet, Sie am Anmelden zu hindern, oder eine Möglichkeit, sich auch nach Ihnen anzumelden habe versucht das zu verhindern. Wenn Sie einen physischen Zugang haben, besteht möglicherweise keine Notwendigkeit für eines dieser Dinge, obwohl die Implementierung eines Paares in Betracht gezogen werden sollte, wenn Sie daran interessiert sind, keine Unannehmlichkeiten zu verursachen.

-John Crout

Eine Möglichkeit wäre, sicherzustellen, dass dies /etcnicht beschreibbar ist. Von niemandem, solange es einen gibt sudoer.

Dies kann geschehen, indem Sie es über das Netzwerk einbinden und auf der anderen Seite sicherstellen, dass das Gerät nicht beschrieben werden kann.

Dies kann mit einem lokalen Gerät geschehen, das den Schreibzugriff auf das Gerät verhindert. ( write blockerHardware nachschlagen )

Der wichtige Teil ist, dass die Einschränkung außerhalb des Root-Konzepts dieser Maschine gelten muss. Ein kreativer Hacker findet seinen Weg um alle Hindernisse, die Sie in der von ihm kontrollierten Umgebung auf sie stellen. Wenn root also sein Passwort ändern könnte, kann a sudoer.

Um sicherzugehen, dass der Benutzer auch Ihre Anmeldefähigkeiten nicht vermasseln kann, müssen Sie read-only /binund gemountet haben /sbin.

Außerdem benötigen Sie ein Skript, das die Netzwerkverbindung regelmäßig wiederherstellt.

(Als Randbemerkung: Wenn Sie dem Sudoer nur einen sehr begrenzten Satz von Befehlen erlauben und für jeden von ihnen sicherstellen, dass sie nicht aus ihnen ausbrechen / sie ersetzen usw. können, dann können Sie dies verhindern, während Sie /etcbeschreibbar sind.)