Es war schon immer meine Ideologie, dass man als Benutzer unter Linux alles machen kann, was man will, und für alles andere gibt es immer etwas sudo. sudoErmöglicht das Ausführen weniger Dinge als einige andere Benutzer, meistens rootfür die Systemadministration. sudoEs war eine Ressource mit einem größeren Vorteil, einige meiner Routineaufgaben und -berechtigungen als (Root-) Benutzer an andere zu delegieren und dabei zu helfen, meine und andere Zeit besser zu verwalten, ohne die Berechtigungen über das erforderliche Maß hinaus zu erhöhen. Gleichzeitig ist es mein Vertrauen, dass ihre Einträge im Internet präsent bleibensudoersKonfigurationsdatei. Ich bin mir nicht sicher, ob es damit zusammenhängen könnte, aber ich kann sagen, dass sudo Ihnen eine bessere Sicherheitsperspektive bietet, wer alle und was sie mit ihren vertrauenswürdigen Berechtigungen tun können. Auch wenn etwas schief geht, sind sie dafür verantwortlich. (Ich kann mit den Log-Informationen der Sudoer immer ein bisschen hinterhältig sein, um auch die Schuldigen zu finden). Meine Kollegen haben mir immer ihre Sorge zum Ausdruck gebracht, dass sie sudo für alles eingeben müssen, was sie mit erhöhten Rechten in einer Linux-Umgebung tun wollten. Auch hier habe ich die gleiche Frage gefunden.
Um die Lösungen und meine Suche nach Alternativen zu sehen, bin ich auf Resource Based Access Controls gestoßen, RBAC aber in einem anderen Abenteuerland Solarismit Tools wie pfexecusw. Dieser Ansatz ist besser, da hierdurch die Rechte der Benutzer, die bereits erhöht sind, erhalten bleiben und sie vertrauen auf das Gewissen und die Wachsamkeit dessen, was Sysadmins mit ihren Privilegien machen möchten.
In Anbetracht der verfügbaren Lösungen von RBAC und seiner Implementierungen in der Linux-Welt bin ich auf gestoßen
SELinux http://www.ibm.com/developerworks/linux/library/l-rbac-selinux/
grsecurity http://de.wikipedia.org/wiki/Grsecurity
und während es einige andere Implementierungen gibt, würde ich sie in der obersten Reihenfolge der Liste betrachten. Die Implementierung von RBAC ist in einer Organisation sehr aufwändig, insbesondere wenn viele Benutzer vorhanden sind. RBAC wäre in homogenen Umgebungen eine bessere Lösung. Wenn sich jedoch heterogene Unix-Installationen im Netzwerk befinden und die Benutzerdatenbank häufig verwendet wird, schlägt dies möglicherweise fehl. Da SELinux unter Solaris nicht skalierbar / implementiert ist, sind RBAC / pfexec-Tools unter Linux nicht implementiert. Es gibt verschiedene Ansätze, um eine einzige Sache zu tun. Zum Beispiel: http://blogs.oracle.com/darren/entry/opensolaris_rbac_vs_sudo_howto
Netzwerkweit unterschiedliche Installationen unterstützen diesen Ansatz möglicherweise nicht (openrbac könnte jedoch als allgemeiner Implementierungsansatz angesehen werden), da sudoers ein Einzelhost-Ansatz ist oder keine zentralisierte Konfiguration im Netzwerk / in der Domäne ermöglicht./etc/sudoersmüssen bei jeder Änderung synchronisiert werden. Auch wenn für den Betrieb der sudoers-Datei eine Wissensdatenbank erforderlich ist, muss die Richtliniensprache der sudoers-Konfiguration verstanden werden, um Fehler zu vermeiden und Berechtigungen zu gewähren. Während die Sicherheitsprofile häufig verwendet werden, kann RBAC einen zentralisierten Ansatz bieten. Das Hinzufügen / Entfernen eines Benutzers aus der zugewiesenen Rolle kann an einem einzelnen Ort erfolgen (d. H. An dem die Benutzer- / Kennwort- / Gruppeninformationen gespeichert werden) die Domain wie LDAP, NIS oder AD). Dies würde auch implizit voraussetzen, dass Sie die Befehle verstehen, die für die Ausführung der RBAC-Datenbank erforderlich sind, z. B. smexec, smmultiuser, nur wenige.
Sudo bietet hier möglicherweise einen plattformübergreifenderen Ansatz, der auf allen Unix- / ähnlichen Plattformen funktioniert, die die setuid-Funktionen bieten. Beides sudound es RBACgelingt den Nicht-Root-Benutzern, einige Berechtigungen zu erteilen, die ohne die Angabe des rootKennworts selbst ausgeführt werden können. Sudo kann die Befehlszeilenargumente, die während der Ausführung der Befehle verwendet werden können, präziser und detaillierter behandeln und sich darauf beschränken, welche Befehle mit Argumenten mit erhöhten Rechten ausgeführt werden können. RBAC kann die Verwendung auf die installierten Befehle oder Binärdateien beschränken, hat jedoch keine Kontrolle über die Befehlszeilenargumente. Auditing ist viel besser und in die RBAC-Umgebung integriertsudoDies hängt von der Konfiguration und auch von den Sicherheitsbeschränkungen ab (zum Beispiel, dass die Shell nicht gewährt wird und insbesondere die Hosts sich problemlos bei den anderen Hosts anmelden dürfen). Dies sind nur einige der Unterschiede, die ich anführen könnte, und ich persönlich neige dazu, sudo als RBAC zu verwenden, obwohl ich mit den genannten Einschränkungen einige Umgehungsmöglichkeiten schaffen könnte. Solange RBAC nicht alle Probleme zum Vorteil von sudo angeht, glaube ich nicht, dass sudo verschwinden wird, denn es ist einfach.