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 haben, von Fall zu Fall die Berechtigung zum Rooten 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-Aktualisierungen von root oder mit sudo-Berechtigungen ausgeführt werden, kann apt-get bestimmte unerwünschte Dateien während der Aktualisierung ersetzen.

Wenn ich diese Berechtigungen für diese einzelnen Dateien verweigern könnte, könnte ich sie als Simlink zu /dev/nulleiner leeren Platzhalterdatei festlegen oder möglicherweise über Berechtigungen verfügen, die das Ersetzen der Datei während der Aktualisierung verweigern würden.

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 (unter Bezugnahme auf die Ubuntu-Entwickler), "weil wir root haben "Dies war ein Verweis darauf, wie Systemaktualisierungen mit Root - Berechtigung durchgeführt werden.

Es interessiert mich überhaupt nicht, die Installationsprozedur zu ändern, um dieses Problem zu umgehen. Jetzt, da mein Verstand die Idee liebt, Root-Zugriff zu verweigern, möchte ich einen Weg finden, wie dies geschehen kann, um dies zu tun.

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

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

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

Ich möchte einen tatsächlichen Benutzer höher im 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 benutzen, wenn ich mich negativ darüber fühlen würde.

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 dies ist root). Sie können diese Vorgänge jedoch auch für gettydie untergeordneten Prozesse zulassen , damit Sie sie manuell ausführen können.

Sie verstehen das Konzept des rootBenutzers falsch .

Befindet sich im Klartext rootoben auf dem Baum.

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

Die hier angegebenen Lösungen - einschließlich AppArmor und SELinux - ändern dies nicht wirklich. Sie ermöglichen einfach eine genauere Kontrolle über rootBerechtigungen und Prozesse.

Es scheint mir, dass Ihr Update-Prozess nicht für das gewünschte Ergebnis geeignet ist. Aber das ist überhaupt kein Fehler des rootBenutzers. Anstatt die Dinge zu rootkomplizieren, sollten Sie sich den Benutzer mit der höchsten Berechtigungsstufe vorstellen, und ansonsten müssen Sie nach unten arbeiten.

Ich weiß, dass einige Leute dies vermerken 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 rootBerechtigungen funktionieren. Sie erstellen jedoch keinen neuen Benutzer mit höheren Berechtigungen.

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

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 wird in der Lage sein, ihnen etwas anzutun, wenn das Flag nicht entfernt wird. Es ist auch möglich, das Container / Namespace-System zu verwenden, um den Root-Zugriff zu verhindern.

• Anstatt einen Super-Super-User zu haben, können Sie root einschränken. Siehe Was sind die verschiedenen Möglichkeiten, Dateiberechtigungen usw. unter gnu / linux festzulegen?

• Es gibt auch AppArmor und SELinux.

• Und / oder konfigurieren Sie sudo, damit Sie nicht die vollen Root-Rechte preisgeben. 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 etc (docker macht das)
  • Xen
  • Virtualbox

• Siehe auch etckeeper: Diese Tool-Revision kontrolliert das /etcVerzeichnis 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 in ein Firewall-Backup-Repository zu übertragen.

• Verwendung der Versionskontrolle im Allgemeinen mit einem Backup-Repository mit Firewall. Dies hilft bei versehentlichen, absichtlichen Beschädigungen 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.

Für Software wie APT , die im Normalbetrieb den Zugriff auf fast das gesamte System erfordert, ist die Einschränkung problematisch. Selbst wenn Sie verhindern, dass es auf bestimmte Teile des Systems zugreift, gibt es höchstwahrscheinlich mehr als genug Möglichkeiten, die ein böswilliger Distributor umgehen kann. Zum Beispiel durch Ersetzen einer Bibliothek oder nur einer Binärdatei oder Hinzufügen einer böswilligen Konfigurationsänderung, die der uneingeschränkte Root möglicherweise verwenden wird.

Abhängig davon, wie viel Sie Beschränkungen auferlegen würden, kann erwartet werden, dass einige Installationsskripts nicht mehr 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 Distributionen unterstützen AppArmor besser, während Fedora / RHEL-basierte Distributionen standardmäßig SELinux aktivieren.

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

Die AppArmor-Richtliniensprache definiert eine Verweigerungsregel , mit der eine Richtlinie für die Sperrliste erstellt werden kann . Ein guter Ort, um mit AppArmor zu beginnen, sind AppArmor- Manpages , Wiki und die Suche nach der vorhandenen Konfiguration in Ihrer Distribution /etc/apparmor.d/.

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

Ich kann nicht glauben, dass niemand das passende Anheften erwähnt hat ...

Vor ein paar Jahren veröffentlichte Microsoft einen Patch, mit dem Windows 10-Computer nicht mehr mit unseren alten Samba NT4-Domänencontrollern kommunizieren konnten. Als das Problem gefunden wurde, haben wir das Samba-Paket fixiert, um auf der aktuellen Version zu bleiben, und aptes funktionierte weiterhin ordnungsgemäß.

Eine vollständige Debian-exemplarische Vorgehensweise erklärt den Prozess gut:

Fügen Sie in /etc/apt/preferences(oder in einer neuen Datei unter /etc/apt/preferences.d/) Text hinzu, um anzugeben, welches Paket und welche Version verwendet werden soll:

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

Überprüfen Sie die Dokumentation auf die genaue Syntax, aber auf diese schnelle und fehlerhafte Weise haben wir eine Paketversion gepinnt. Root könnte es umgehen, wie es Root immer tun kann, aber dies löst das Problem der Paketmanager, die versuchen, Pakete auf Ihnen automatisch zu aktualisieren.

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

Es ist eigentlich ganz einfach.

Root ist dein "Super Super User"

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

Dann erstelle einen Benutzer namens bob und lass ihn "admin werden". Mit su oder sogar sudo.

Jetzt haben Sie einen normalen Benutzer (Bob), einen Super-Benutzer, der Admin-Aufgaben erledigen kann (Admin), und einen Super-Super-Benutzer (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.

Wenn Sie lediglich verhindern möchten, dass bestimmte Dateien installiert werden, ist das Einschränken der Root-Berechtigungen nicht der richtige Weg, 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 keine Dateien installieren können.

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.

In Bezug auf diese Frage bin ich mir nicht 100% sicher, aber ich weiß, dass einige andere Paketmanager Optionen haben, um zu verhindern, dass bestimmte Dateien installiert werden (zum Beispiel hat Gentoos Portage-System die Option INSTALL_MASK=, die tatsächlich Shell akzeptiert -Stil passende Muster von Dingen, 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) besteht.

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, die Installation zu vermasseln, aber Sie erhalten trotzdem die Datei (en) zurück, die Sie behalten möchten.

Arbeiten Sie von einem bereitgestellten Laufwerk aus

Beachten Sie, dass dies hauptsächlich eine konzeptionelle Antwort ist, aber ich denke, es sollte funktionieren und im Geiste dessen sein, was Sie erreichen möchten.

Lassen Sie System X Ihr Arbeitssystem sein und System Y ein anderes System, 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 auf alle Rechte in diesem bereitgestellten Laufwerk zugreifen kann

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

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, Validierungen usw. einzufügen. Dies wäre eine gültige, potenziell nützliche Methode ein Unix-Typ-System mit einem "Benutzer" (eigentlich eine Funktion des Hypervisors) zu implementieren, um "Dinge zu tun, die selbst root nicht kann"

Ich habe das Gefühl, dass dieser Ansatz wahrscheinlich übertrieben ist

Werfen Sie einen Blick auf cgroups und Linux-Namespaces als alternative Methode zur Erreichung dieses Ziels sowie auf darauf basierende Tools wie Docker und lxd .

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

DEINSTALLIEREN sudo

Wie wäre es mit Deinstallation sudound Symlink /bin/suzu /bin/false? Stellen Sie sicher, dass Sie rootsich nicht über einloggen können sshund das System gesperrt ist.

Das macht rootden 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. Realistischer, um die Berechtigungen der Dateien ändern 440oder 444so sie nicht geschrieben werden können. Oder legen Sie sie in ein Git-Repository, damit sie zurückgesetzt werden können, wenn sie überschrieben werden.