Root-Zugriff, der das Root-Passwort nicht ändern kann?

66

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?

244an
quelle
32
Sie können sudodie Berechtigung nur für bestimmte Anwendungen mit Root-Rechten erteilen. Auf diese Weise kann der Benutzer das root-Passwort nicht ändern
SHW
24
WARUM brauchen Sie sudofür diese Benutzer ? Wenn Sie ihnen nicht vertrauen, geben Sie ihnen erst keinen sudoZugang. Beachten Sie auch, dass root im Idealfall überhaupt kein Kennwort haben sollte , aber Sie sollten andere Authentifizierungsmethoden verwenden. (Was der Benutzer noch in der Lage sein wird, "zu hacken", auch wenn Sie protext /etc/passwd)
Anony-Mousse
3
Was müssen diese Benutzer genau tun?
Olivier Dulac
4
Was werden sie mit ihren Root-Rechten machen? Es könnte eine bessere Lösung geben, als Sie denken.
Sparticvs
23
Dies ist eine der folgenden Fragen: "Kann Gott einen Felsbrocken so groß machen, dass er ihn selbst nicht heben kann?" Fragen eingeben. Wenn Sie Root-Zugriff haben, können Sie alles tun, weshalb Root-Zugriff am besten mit Bedacht gewährt wird. sudound setuidkann die meisten Probleme lösen.
bsd

Antworten:

57

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.

ein CVn
quelle
3
Es tut mir leid, dass meine Antwort den ganzen Hype bekommen hat (ich verstehe es nicht ganz!). Ihre Antwort wirft hervorragende Punkte auf und ich hoffe, dass sie akzeptiert wird. +1 an Sie, Sir.
Joseph R.
@ JosephR. manchmal ist eine prägnante Antwort vorzuziehen.
David Cowden
@ DavidCowden Ja, es scheint, dass dies hier der Fall ist ...
Joseph R.
1
@ JosephR. Keine Sorge für mich. Die Stack Exchange-Community ist nicht immer vorhersehbar, und Fragen, die bereits viele positive Stimmen haben, ziehen tendenziell mehr an. Vielen Dank für die positive Bewertung. :)
ein Lebenslauf vom
92

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
[email protected]
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, [email protected]keine 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.

Joseph R.
quelle
Wie hast du diesen coolen Verweis auf einen Kommentar gemacht? Ich habe die Quelle nach Ihrer Antwort durchsucht und gesehen, dass () sie umgibt. Cooler geheimer Hut!
Joe
@ Joe Die Zeit, zu der ein Kommentar gepostet wurde, ist eigentlich ein Link zum Kommentar.
Joseph R.
@Joe Finde die ID ( <tr id="thisistheid"...) des Kommentars (z. B. in Chrome mit der rechten Maustaste und Inspect element) und hänge sie mit einem vorangestellten an den Thread-Link an #. In Ihrem Fall (id = comment-162798) sieht es so aus: unix.stackexchange.com/questions/105346/…
polym
1
Vielen Dank für die Antwort, ich wusste nicht, ob ich dies oder jenes von @Michael Kjörling akzeptieren sollte, ich wählte sein, weil das mehr Beschreibung hat - benötigt von einem Noob wie mir :) Aber deins war auch hilfreich
244an
@ 244an Keine Sorge. Ich hätte das auch selbst empfohlen . :)
Joseph R.
17

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.

Anony-Mousse
quelle
6
Dies hindert den Benutzer nicht daran toor, das root-Passwort zu ändern. Es wird nur ein zweites Kennwort bereitgestellt, mit dem Sie sich als Root anmelden können.
Alexis
2
-1 dann. Sie schlagen ein Backdoor-Passwort vor, damit die Administratoren den Root-Zugriff wiederherstellen können, nachdem sie es verloren haben? Das ist einfach falsch und außerdem könnten die nervigen Benutzer es leicht deaktivieren, wie Sie sagen. Es gibt viel zuverlässigere Möglichkeiten, eine Hintertür einzurichten.
Alexis
2
@alexis Das ist es, wonach IMHO der Autor der Frage gefragt hat. Warum geben Sie -1 dafür? toorWiederherstellungskonten sind unter Unix seit Jahrzehnten eine gängige Praxis (obwohl sie verpönt sind).
Anony-Mousse
9
Wenn das einzige Ziel darin besteht, versehentliche Kennwortänderungen zu verhindern , ist dies eine gute Antwort. Wenn das Ziel darin besteht, böswillige Aktivitäten zu verhindern, ist dies keine große Hilfe. Da das OP nicht sagte, was das Ziel war, wissen wir es nicht.
Bobson
2
Deshalb habe ich in meinem ersten Satz gesagt: "Mist gebaut ... ansonsten vertraust du ... voll". Dies ist eigentlich nur eine "Support Access" -Lösung. kein Sicherheitsmerkmal. Die Verwendung zusätzlicher Root-SSH-Schlüssel bewirkt dasselbe, ohne hackisch zu sein.
Anony-Mousse
11

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.

alexis
quelle
Das Problem ist jedoch, dass Sie den Angreifer nicht davon abhalten können, durch einen Exploit Wurzel zu schlagen. SELinux bietet umfassende Verteidigung.
Timothy Leung
11

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.

rjmunro
quelle
8
Dies mit SELinux zu tun, mag theoretisch möglich sein (und ich bin nicht davon überzeugt), zu behaupten, dass es ohne das Zeigen tatsächlicher Regeln geht, wird niemandem helfen.
Gilles
@Gilles gut tatsächlich , ist es das , was SELinux entworfen wurde. SELinux ist eine Ebene von Berechtigungen, die zusätzlich zu den POSIX-Standardberechtigungen erforderlich sind . Auf einem ordnungsgemäß konfigurierten SELinux-Computer ist der Root-Zugriff bedeutungslos, da Ihre tatsächlichen Berechtigungen durch den Sicherheitskontext und die Objektkennzeichnung bestimmt werden.
Tyler
2
Wenn Sie wissen, wie es geht, antworten Sie bitte auf Mythos oder Realität: SELinux kann den Root-Benutzer einschränken?
Gilles
Theoretisch kann es mit SELinux noch möglich sein; Das Einrichten von so etwas müsste jedoch komplexer sein, um eine robuste Trennung von ALLEN SELinux-bezogenen Konfigurationsdateien vom "normalen" Dateisystem (auf das der rootBenutzer vollen Zugriff hat) zu gewährleisten . Letztendlich wäre die "einfachste" Methode für eine solche Trennung (mit oder ohne SELinux), mit so etwas wie Kerberos zu arbeiten, wie von Joseph R.
ILMostro_7,
7

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.

DSimon
quelle
Dies wäre sicherer als viele der Optionen IMHO.
Elder Geek
5

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

SHW
quelle
3
Es besteht immer die Möglichkeit, dass ein böswilliger Benutzer dieses Skript liest und die Sicherungskopie beschädigt.
Joseph R.
Das ist auch so ziemlich das, was vipwFreunde schon tun.
ein Lebenslauf vom
Betrachten wir es als Programm und nur als root
SHW
1
rootkann den "anderen Ort" danach bearbeiten sudo.
Anony-Mousse
5
Warum würden Sie einem potenziell böswilligen Benutzer den Root-Zugriff gewähren? Als root ist es trivial, eine Hintertür zu installieren, die nicht von sudo und / oder dem Wrapper abhängt ...
alexis
5

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
RobotHumans
quelle
In dieser Antwort wird erläutert, wie Sie sudo für den eingeschränkten Root-Zugriff einrichten. Es ist jedoch viel besser, wenn die Antwort so lautet und wohin dies führen sollte.
ein CVn
@ MichaelKjörling erledigt
RobotHumans
3
"Die Aussage, dass sudo nur zur Vergabe von root gedacht ist und es danach keinen Schutz mehr gibt, ist offensichtlich falsch." Angenommen, ich erteile sudo vieinem Benutzer Zugriff, damit er Systemkonfigurationsdateien bearbeiten kann. Dieser Benutzer führt dann :!/bin/basheine sudo viSitzung aus. Wie hilft die Fähigkeit von sudo, die Befehle einzuschränken, die ein Benutzer über sudo ausführen kann, mein System unter diesen Umständen zu schützen? (Niemand hat gesagt, dass sudo nicht enger konfiguriert werden kann als ein Alles-oder-Nichts- sudo -iAnsatz.)
ein Lebenslauf vom
6
Das Verständnis der Grenzen eines Ansatzes ist ebenso wichtig wie das Wissen, wie eine Aufgabe auszuführen ist.
ein Lebenslauf vom
1
@ MichaelKjörling, ich denke das ist nur ein Beispiel. Um jedoch klar zu sein, können Benutzer die Systemkonfigurationsdateien ordnungsgemäß bearbeiten, indem sie ausgeführt werden sudoedit. Sie können spezifisch identifizieren, welche Dateien sie können sollten sudoedit. Das ist in man sudoers.
Matthew Flaschen
3

(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)

9mjb
quelle
3

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:

Animismus
quelle
2

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 ...)

Darren Cook
quelle
2
Nein. Wie Michael so treffend feststellte , kann ein böswilliger Benutzer den Root-Zugriff verhindern, ohne das Kennwort zu missbrauchen, indem er einfach die Binärdateien durcheinanderbringt. Sogar der init=...Ansatz kann verhindert werden, indem Ausführungsberechtigungen von relevanten Binärdateien entfernt werden. Ich denke, eine bessere Lösung in diesem Fall ist es, Ihr Root-Dateisystem über LiveCD zu mounten und den Schaden (zu versuchen) zu beheben. Wenn Sie jedoch der Meinung sind, dass das System kompromittiert wurde, ist es besser, die Wiederherstellung aus einer Sicherungskopie durchzuführen.
Joseph R.
Zustimmend @JosephR; Das Erkennen und Beheben von Schäden ist kompliziert, und ich würde sie auch neu installieren. Aber ich vermute, die Sorge des OP galt eher der Tatsache, dass jemand sie versehentlich ausgesperrt hat ... absichtliches Hacken in einer Arbeits- oder Schulsituation ist ein bisschen selbstmörderisch. ;-)
Darren Cook
1
Nicht unbedingt. Ein wirklich böswilliger Benutzer in Kombination mit einem sorglosen / ahnungslosen Systemadministrator kann unentdeckte Rechte eskalieren. Ich bin damit einverstanden, dass die ursprüngliche Absicht des OP darin bestand, unschuldige Fehler abzuwehren, anstatt sich vor böswilligen Absichten zu schützen, aber die Frage wurde mit "Sicherheit" markiert, und wir sind einfach damit gefahren, denke ich :)
Joseph R.
2

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.

SevenSidedDie
quelle
2

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.

FooF
quelle
1

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.

Veniamin
quelle
0

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

ehime
quelle
-1

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.

martin
quelle
Es ist einfach, der eingeschränkten Bash zu entkommen. Sehen Sie sich diesen Sans-Blog an
Franklin Piat,
-1

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

John Crout
quelle
sudoist enorm unterschiedlich su -. Dies wurde wiederholt darauf hingewiesen, zum Beispiel durch SHW , Joseph R. , mich , hbdgaf und möglicherweise einige mehr das Kommentarfeld zu kurz schließen ...
ein CVn
Alles wahr, aber irrelevant. Sie erörtern alternative Möglichkeiten, Root zu werden, und das Risiko, Root-Zugriff zu gewähren, aber nichts, was sich auf „Root-Zugriff, der das Root-Passwort nicht ändern kann“ auswirkt.
Gilles
Wahr. Die Frage ist ein logisches Oxymoron; Es kann nur existieren, wenn die Installation fehlerhaft ist. Was nützt ein Benutzer-Login / Konto, bei dem dieser Benutzer sein Passwort nicht ändern kann, aber dennoch Root-Zugriff hat? Daher gelten die angebotenen Vorschläge für das, was der Fragesteller möglicherweise gemeint hat. nicht so, wie sie die Frage geschrieben haben. Jede Zugriffskontrollmethode birgt ein Risiko.
John Crout
-3

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.)

Angelo Fuchs
quelle
Das Mounten von / etc ist zwar schreibgeschützt, aber möglicherweise möglich (Sie müssen z. B. beim Pivot-Root in den Boot-Skripten des initrd vorsichtig sein), aber es besteht die Gefahr, dass das Setup ziemlich fragil ist. Es gibt auch viele Dinge, die ein Benutzer mit Root-Zugriff tun kann, die die Fähigkeit anderer Benutzer beeinträchtigen, Root-Rechte zu erlangen, ohne Änderungen in / etc. Vorzunehmen.
ein Lebenslauf vom
@ MichaelKjörling Das Setup ist nicht zerbrechlich, ich benutze es oft (als schreibgeschützte lokale Mounts).
Angelo Fuchs
@ MichaelKjörling Ich habe einige andere Elemente hinzugefügt, die schreibgeschützt sein sollen, wenn Sie sicherstellen möchten, dass Sie sich weiterhin anmelden können. Die Liste der Aktionen, die ausgeführt werden müssen, wenn Sie diesen Weg beschreiten, ist also nicht so kurz, aber "Dies ist die einzige Möglichkeit, um sicherzustellen, dass wir uns weiterhin auf diesem Server anmelden und root werden können, unabhängig davon, was die anderen Benutzer tun."
Angelo Fuchs
Ich gebe zu, ich habe noch nie die Notwendigkeit gesehen, es zu versuchen, aber eine Sache, die ich definitiv sehen kann, wäre riskant, wie init damit umgehen wird, dass / etc / inittab unter seinen Füßen ausgetauscht wird. Oder was das System tun wird, wenn die anfängliche und die nachträgliche Bereitstellung von / etc / fstab unterschiedlich sind. Und es gibt / etc / mtab. Andere Benutzer möchten möglicherweise ihre eigenen Kennwörter ändern, was das Schreiben in / etc / shadow und möglicherweise in / etc / passwd umfasst. Und mount / etc read-only ist immer noch nur eine Teillösung. Ich sage nicht, dass es nicht Teil einer Lösung sein kann, aber es ist sicherlich nicht der erste Schritt, den ich in der Situation des OP unternehmen würde.
ein Lebenslauf vom
1
Ja. Dies zu tun ist gefährlich und hat ernsthafte Probleme, wenn es falsch gemacht wird. Soweit ich weiß, ist dies immer noch die einzige Möglichkeit, die OPs-Anfrage für Benutzer zu lösen, denen es gestattet sein sollte, root zu werden.
Angelo Fuchs