it-swarm.com.de

Kann ich einen * Super * Superuser erstellen, damit ich tatsächlich einen Benutzer habe, der die Berechtigung zum Rooten verweigern kann?

Ich dachte, dass es vorteilhaft sein könnte, einen Benutzer mit höheren Berechtigungen als den Root-Benutzer zu haben.

Sie sehen, ich möchte alle Aktivitäten und fast alle vorhandenen Root-Benutzerrechte genau so behalten, wie sie jetzt sind.

Ich möchte jedoch die Möglichkeit, die Berechtigung zum Rooten von Fall zu Fall extrem isoliert zu verweigern.

Einer der Vorteile davon würde es mir ermöglichen, zu verhindern, dass bestimmte unerwünschte Dateien während Updates installiert werden. Dies ist nur ein Beispiel für einen möglichen Vorteil.

Da apt-get-Updates von root oder mit Sudo-Berechtigungen ausgeführt werden, kann apt-get bestimmte unerwünschte Dateien während Updates ersetzen.

Wenn ich diese Berechtigungen für diese einzelnen Dateien verweigern könnte, könnte ich sie als Simlink zu /dev/null Festlegen oder möglicherweise eine leere Platzhalterdatei mit Berechtigungen haben, die das Ersetzen der Datei während des Updates verweigern.

Außerdem kann ich nicht anders, als an eine Zeile erinnert zu werden, die in einem Interview mit einem der Ubuntu-Entwickler gesagt wurde, als der Typ etwas darüber sagte, wie Benutzer "uns" besser vertrauen (bezogen auf die Ubuntu-Entwickler), "weil wir root haben "Dies war ein Hinweis darauf, wie Systemaktualisierungen mit Root-Berechtigung durchgeführt werden.

Es ist absolut nicht das, was mich hier interessiert, einfach das Installationsverfahren zu ändern, um zu sagen, dass dieses Problem umgangen werden kann. Jetzt, da mein Verstand die Idee hat, die Möglichkeit zu haben, den Root-Zugriff zu verweigern, möchte ich einen Weg finden, dies zu erreichen, nur um dies zu tun.

Ich habe nur darüber nachgedacht und bisher keine Zeit mit der Idee verbracht und bin ziemlich zuversichtlich, dass dies herausgefunden werden kann. Ich bin jedoch gespannt, ob dies bereits geschehen ist oder ob dies möglicherweise keine neue Idee oder ein neues Konzept ist.

Grundsätzlich scheint es eine Möglichkeit zu geben, einen Super-Superuser zu haben, der nur um einen Grad über die Berechtigung des Systems hinausgeht.


Hinweis: Obwohl ich der Meinung bin, dass die akzeptierte Antwort den Kriterien am besten entspricht, gefällt mir die Antwort von @CR sehr gut. ebenfalls.

Ich möchte einen tatsächlichen Benutzer höher auf dem Baum (ich) erstellen, aber ich denke, ich muss mich nur eines Tages hinsetzen, wenn ich die Zeit habe, es herauszufinden.

Außerdem versuche ich hier nicht, Ubuntu auszuwählen. Ich würde es nicht als meine Hauptdistribution verwenden, wenn ich mich negativ dabei fühle.

34
mchid

Der gewünschte "Benutzer" heißt LSM: Linux-Sicherheitsmodul. Die bekanntesten sind SELinux und AppArmor.

Auf diese Weise können Sie verhindern, dass bestimmte Binärdateien (und ihre untergeordneten Prozesse) bestimmte Aufgaben ausführen (auch wenn ihre UID root lautet). Sie können diesen Vorgängen jedoch erlauben, getty und seine untergeordneten Prozesse auszuführen, damit Sie dies manuell tun können.

83
Hauke Laging

Sie verstehen das Konzept des Benutzers root falsch.

Im Klartext steht root an der "Spitze des Baumes".

Was ist, wenn Sie sich eines Tages für einen "Super-Super-User" und dann nächsten Monat für einen "Super-Super-Super-User" (!) Entscheiden? Wie weit "hoch" der Baum möchten Sie gehen? Wie würden Sie alle Berechtigungen und Hierarchien mischen, damit dies funktioniert? Wer ist immer an der Spitze? Jemand muss oben sein und es ist root. Ende der Geschichte.

Die hier angegebenen Lösungen - einschließlich AppArmor und SELinux - ändern dies nicht wirklich. Sie ermöglichen einfach eine feinere Kornkontrolle über root Berechtigungen und Prozesse.

Es klingt für mich so, als ob Ihr Update-Prozess nicht für das gewünschte Ergebnis geeignet ist. Aber das ist überhaupt kein Fehler des Benutzers root. Anstatt die Dinge zu komplizieren, stellen Sie sich root als den Benutzer mit der höchsten Berechtigungsstufe vor, und dann müssen Sie alles andere nach unten arbeiten.

Ich weiß, dass einige Leute dies notieren werden, aber es gibt keine höhere Ebene in der Benutzerhierarchie, und alle anderen Lösungen geben einfach eine etwas andere Kontrolle darüber, wie root Berechtigungen funktionieren. Sie erstellen jedoch keinen neuen Benutzer mit höheren Berechtigungen.

Sie können keinen Benutzer mit "mehr Berechtigungen" als root haben, da root die höchstmögliche Berechtigungsstufe darstellt. Die Verwendung eines Ausdrucks wie "mehr Kontrolle als root" ist ein Widerspruch - root hat die volle Kontrolle und alle möglichen Berechtigungen, daher kann darüber nichts getan werden.

51
Andy

Wenn Sie nur verhindern möchten, dass Dateien oder Verzeichnisse geändert/gelöscht werden, setzen Sie einfach das unveränderliche Flag auf diese.

chattr +i <file>

Nicht einmal root kann ihnen etwas antun, wenn das Flag nicht entfernt wird. Es ist auch möglich, das Container-/Namespace-System zu verwenden, um den Root-Zugriff zu verhindern, aber das scheint ein Overkill für das zu sein, was Sie benötigen.

26
CR.
  • Anstatt einen Super-Super-Benutzer zu haben, können Sie root einschränken. siehe Was sind die verschiedenen Möglichkeiten, um Dateiberechtigungen usw. unter gnu/linux festzulegen

  • Es gibt auch AppArmor und SELinux.

  • Und/oder konfigurieren Sie Sudo, damit Sie nicht die vollständigen Root-Berechtigungen vergeben. Sie können es so einrichten, dass ein Benutzer nur vorab vereinbarte Befehle mit vorab vereinbarten Argumenten ausführen kann.

  • Sie können die Virtualisierung auch verwenden, um root einzuschränken:

    • cgroups, Namespaces, Chroot usw. (Docker macht das)
    • Xen
    • Virtualbox
  • Siehe auch etckeeper: Diese Tool-Revision steuert das /etc Verzeichnis und synchronisiert mit apt. Standardmäßig ist es nicht sicher, eine böswillige Installation könnte es sabotieren, aber Sie könnten es auch dazu bringen, Änderungen an ein Backup-Repository mit Brandmauern zu übertragen.

  • Verwendung der Revisionskontrolle im Allgemeinen mit einem Backup-Repository mit Brandmauern. Dies hilft bei versehentlicher, vorsätzlicher Beschädigung und Hardwarefehlern.


Firewall-Backup-Repositorys können sich auf einer anderen Maschine, im Internet oder auf einer anderen virtuellen Maschine (oder einem Host der virtuellen Maschine) befinden.

9
ctrl-alt-delor

Bei Software wie [~ # ~] apt [~ # ~] , die im normalen Betrieb Zugriff auf fast das gesamte System erfordert, ist das Einschränken problematisch. Selbst wenn Sie verhindern, dass es auf bestimmte Teile des Systems zugreift, gibt es höchstwahrscheinlich mehr als genug Möglichkeiten, um böswillige Distributoren zu umgehen. Zum Beispiel durch Ersetzen einer Bibliothek oder nur einer Binärdatei oder Hinzufügen einer böswilligen Konfigurationsänderung, die der uneingeschränkte Stamm möglicherweise irgendwann verwenden wird.

Abhängig davon, wie viel Sie einschränken würden, ist zu erwarten, dass einige Installationsskripte nicht funktionieren.

Um Anwendungen und Benutzer einzuschränken, können Sie eine AppArmor- oder eine SELinux-Richtlinie schreiben. Eine solche Richtlinie, die besser unterstützt wird, hängt von Ihrer Distribution ab: Debian-basierte haben eine bessere Unterstützung für AppArmor, während Fedora/RHEL-basierte Distributionen standardmäßig SELinux aktivieren.

Sowohl AppArmor als auch SELinux arbeiten an White-List-Richtlinien , die Regeln enthalten, um bestimmte Aktionen zuzulassen (oder abzulehnen). Richtlinien werden auf einen Prozess bei exec angewendet. Ebenso können Benutzer eingeschränkt werden, wenn beim Anmelden eine Richtlinie auf ihre Prozesse angewendet wird. Eine gut durchdachte Richtlinie kann nicht umgangen werden (wenn Kernel-Fehler nicht berücksichtigt werden). Der als root ausgeführte begrenzte Prozess (UID 0) wird durch die konfigurierte Richtlinie eingeschränkt und kann nur geändert werden, wenn dies in der Richtlinie ausdrücklich zulässig ist.

Die AppArmor-Richtliniensprache definiert eine Verweigerungsregel , mit der eine Blacklist erstellt werden kann Politik . Ein guter Anfang für AppArmor ist AppArmor Manpages , Wiki und das Anzeigen der vorhandenen Konfiguration in Ihrer Distribution in /etc/apparmor.d/.

In SELinux-Wiki finden Sie reichlich SELinux-Administrations- und Entwicklungsmaterial. SELinux Referenzrichtlinie wird auf github gehostet.

8
sebasth

Ich kann nicht glauben, dass niemand passendes Pinning erwähnt hat ...

Vor einigen Jahren veröffentlichte Microsoft einen Patch, der Windows 10-Computer daran hinderte, mit unseren alten Samba NT4-Domänencontrollern zu kommunizieren. Als das Problem gefunden wurde, haben wir das Samba-Paket angeheftet, um die aktuelle Version beizubehalten, und apt funktionierte immer noch ordnungsgemäß.

Ein vollständiger Debian Walkthrough erklärt den Prozess gut:

Im /etc/apt/preferences (oder eine neue Datei unter /etc/apt/preferences.d/), fügen Sie Text hinzu, um anzugeben, welches Paket und welche Version:

Package: samba
Pin: release v=3.6.6-6+deb7u7
Pin-Priority: 900

Überprüfen Sie die Dokumentation auf die genaue Syntax, aber dies ist die schnelle und schmutzige Art, wie wir eine Paketversion gepinnt haben. Root könnte es umgehen, wie root es immer kann, aber dies löst das Problem, dass Paketmanager versuchen, Pakete auf Sie automatisch zu aktualisieren.

HINWEIS: Bei dieser Antwort wird davon ausgegangen, dass Sie ein XY-Problem haben

7
Canadian Luke

Es ist eigentlich ganz einfach.

Root ist dein "Super Super User"

Erstellen Sie ein Konto mit dem Namen "admin" und geben Sie ihm alle Berechtigungen von root mit Ausnahme derjenigen, die Sie nicht möchten.

Erstellen Sie dann einen Benutzer namens bob und lassen Sie ihn "admin" werden. Mit su oder sogar Sudo.

Jetzt haben Sie einen normalen Benutzer (bob), einen Superuser, der Admin-Aufgaben ausführen kann (admin), und einen Super-Superuser (root).

Wenn Sie den Namen "root" in etwas anderes ändern möchten, können Sie dies sogar tun. Technisch ist nur die Benutzer-ID (0) von Bedeutung.

6
coteyr

Wenn Sie lediglich verhindern möchten, dass bestimmte Dateien installiert werden, ist das Einschränken der Root-Berechtigungen nicht der richtige Weg, um dies zu tun. Es ist auch erwähnenswert, dass die herkömmlichen Antworten (unveränderliche Dateien oder LSMs) für Ihren speziellen Anwendungsfall nicht funktionieren, da APT (und die meisten anderen Paketmanager)) aussteigen, wenn sie können. ' t Dateien installieren.

Die eigentliche Frage, die Sie stellen möchten, lautet:

Gibt es eine Möglichkeit zu verhindern, dass APT) bestimmte Dateien installiert?

Das ist etwas völlig anderes als das, was Sie auf mehreren Ebenen verlangen.

Was diese Frage betrifft, bin ich mir selbst nicht 100% sicher, aber ich weiß, dass eine Reihe anderer Paketmanager Optionen haben, um die Installation bestimmter Dateien zu verhindern (z. B. hat das Portage-System von Gentoo die Option INSTALL_MASK=, das tatsächlich passende Muster im Shell-Stil von Dingen akzeptiert, die nicht installiert werden sollen). Ich wäre mehr als bereit zu wetten, dass eine solche Option für APT (oder möglicherweise dpkg selbst) existiert.

3

Sie könnten einen Typ-1-Hypervisor wie Xen-Hypervisor ausführen und Ihr reguläres Betriebssystem als virtualisierten Gast hosten lassen. Der Hypervisor steuert das virtuelle Gastbetriebssystem auf einer "tieferen" Ebene als root, da er die Kontrolle über die (virtuelle) Hardware hat, auf der das Gastbetriebssystem ausgeführt wird.

Sie können den Hypervisor so programmieren, dass er das Gastbetriebssystem auf verschiedene Arten manipuliert, einschließlich Ändern von Berechtigungen, Erstellen und Anwenden von Sicherungen, Verknüpfen bestimmter Änderungen oder Anweisungen im Gastbetriebssystem, um zusätzliche Funktionen, Validierung usw. einzufügen. Dies wäre eine gültige, potenziell nützliche Methode ein Unix-System mit einem "Benutzer" (eigentlich eine Funktion des Hypervisors) zu implementieren, um "Dinge zu tun, die selbst Root nicht kann"

Mein Gefühl, dass dieser Ansatz wahrscheinlich übertrieben ist

1
Nathan Smith

Bewahren Sie eine Sicherungskopie an einem sicheren Ort auf. Ersetzen Sie nach jeder Installation/Aktualisierung sofort die spezifischen Dateien aus dieser Sicherung. Somit gibt es keine Fehler beim Versauen der Installation, aber Sie erhalten trotzdem die Datei (en) zurück, die Sie behalten möchten.

1
WGroleau

Arbeiten Sie von einem gemounteten Laufwerk aus

Beachten Sie, dass dies meistens eine konzeptionelle Antwort ist, aber ich denke, es sollte funktionieren und im Geiste mit dem sein, was Sie erreichen möchten.

Lassen Sie System X Ihr Arbeitssystem und System Y ein anderes System sein, das Sie steuern

  1. Hängen Sie ein Verzeichnis von Y als Laufwerk in X ein
  2. Richten Sie die Rechte so ein, dass der Root-Benutzer von X mit wenigen Ausnahmen Rechte für alles in diesem bereitgestellten Laufwerk hat

Jetzt haben Sie Ihre "funktionierende Wurzel", die fast alles kann, und Sie haben Ihre "Super-Wurzel", das eigentliche Root-Konto von System Y, das wirklich alles kann.

1

Schauen Sie sich cgroups und Linux-Namespaces als alternative Methode zur Erreichung dieser Art von Ziel sowie darauf basierende Tools wie Docker und an lxd .

Mit diesen Tools können Sie unter anderem einschränken, welche Teile des Dateisystems ein Prozess, der als "root" ausgeführt wird, sehen kann, welche Prozesse für ihn sichtbar sind, und nur bestimmte Funktionen für " root "Benutzer.

1
smw

DEINSTALLIEREN Sudo

Wie wäre es mit der Deinstallation von Sudo und symlink /bin/su bis /bin/false? Verbinden Sie dies mit der Sicherstellung, dass root sich nicht über ssh anmelden kann und Sie das System gesperrt haben.

Das macht root zum Super * Super User, und alle anderen sind dem untergeordnet.

Führen Sie für Dateien, die während der Aktualisierung ersetzt wurden, einfach keine Aktualisierungen durch. Ändern Sie realistischer die Berechtigungen der Dateien in 440 oder 444 also können sie nicht geschrieben werden. Oder legen Sie sie in einem Git-Repository ab, damit sie zurückgesetzt werden können, wenn sie überschrieben werden.

0
user176717