Mit CmndAlias ALL wird niemals sicher sein
Es gibt 1000 Möglichkeiten, service network restart auszuführen ohne sudo service network restart auszuführen . Hier ist ein Beispiel dafür, was ein ungezogener Benutzer versuchen könnte:
$ echo "service network restart" > /tmp/hax
$ chmod a+x /tmp/hax
$ sudo /tmp/hax
Wenn Sie Benutzern den ALL zur Verfügung stellen Befehlsalias verwenden und dann versuchen, eine schwarze Liste zu erstellen, werden sie immer einen Weg finden, sie zu umgehen. Blacklist-Bash, und sie werden Python verwenden. Python auf die schwarze Liste setzen, und sie werden Perl verwenden. Blacklist Perl, und sie werden PHP verwenden. Niemand will das!
Wenn Sie wirklich nicht wollen, dass jemand etwas tut, sollten Sie tun, was Thomas sagt, und eine Whitelist von Dingen erstellen, die er ist darf.
Einrichten einer Whitelist mit einer Ausnahme
Ein Beispiel für eine kleine Whitelist mit einem Ausschluss finden Sie am Ende von man sudoers :
pete HPPA = /usr/bin/passwd [A-Za-z]*, !/usr/bin/passwd root
The user pete is allowed to change anyone's password except for root on the HPPA
machines. Note that this assumes passwd(1) does not take multiple user names
on the command line.
(Tatsächlich ist dieses Beispiel aus der Manpage unsicher und kann ausgenutzt werden, um das Passwort von root zu ändern! Sehen Sie sich die Kommentare unten an, um zu erfahren, wie.)
Wir können versuchen, das an Ihren Fall anzupassen, um alle service anzubieten Befehle an die Mitarbeitergruppe, aber ausschließen die service network Befehle, die Sie betreffen:
%staff ALL = /usr/sbin/service *, \
! /usr/sbin/service *network*, \
! /usr/sbin/service *NetworkManager*
(Die ALL in dieser Position bezieht sich auf den Host_Alias, nicht auf den Cmnd_Alias - verwirrend, nicht wahr?)
Der Benutzer kann sudo bash nicht ausführen oder sudo tee oder sudo wget oder sudo /path/to/malicious_script . Sie können weitere Admin-Befehle für Ihre Benutzer auf die Whitelist setzen, wenn Sie vorsichtig sind. Seien Sie einfach konkret!
Hinweis:Ich habe den * hinzugefügt vor dem Wort network oben, nur für den Fall, dass dem service jemals ein harmloses Flag hinzugefügt wird Werkzeug in die Zukunft. Stellen wir uns einen --verbose vor -Flag hinzugefügt wird, können Benutzer Folgendes ausführen:
$ sudo service --verbose network restart
Also brauchen wir den * um alle Flags vor dem Dienstnamen zu verbrauchen. Der einzige Nachteil ist, dass dies andere Dienste blockieren kann, die Sie eigentlich nicht stören, wenn Benutzer sie ausführen, z. ein Dienst namens safe-network oder network-monitor würde ebenfalls abgelehnt werden.
Erlauben Sie Benutzern, eine Datei mit Gruppenberechtigungen zu bearbeiten
Nachfolgend finden Sie verschiedene Versuche mit rnano bis sudo um Benutzer eine oder mehrere Dateien bearbeiten zu lassen. Aber in Wirklichkeit sind sie komplexer und gefährlicher, als sie sein sollten.
Eine viel einfachere und sicherere Lösung besteht darin, die Gruppenberechtigungen für die spezifischen Dateien zu ändern, für die Sie Bearbeitungsrechte öffnen möchten. Hier sind ein paar Beispiele:
### Give steve the ability to edit his nginx config:
$ chgrp steve /etc/nginx/sites-available/steves_dodgy_project
$ chmod g+rw /etc/nginx/sites-available/steves_dodgy_project
### Let all members of the staff group edit the group_website config:
$ chgrp staff /etc/nginx/sites-available/group_website
$ chmod g+rw /etc/nginx/sites-available/group_website
Wenn Sie eine genauere Kontrolle benötigen (z. B. Zugriff für nur 3 Benutzer, aber nicht alle Mitarbeiter), können Sie mit addgroup eine neue Gruppe erstellen Befehl und fügen Sie ihm nur wenige Benutzer hinzu.
Lassen Sie Benutzer eine Datei über sudo bearbeiten
Der Rest dieser Antwort wurde zu einer Untersuchung darüber, wie einfach es ist, Löcher in Ihrem sudo zu hinterlassen Konfiguration, wenn Sie versuchen, Ihren Benutzern Flexibilität zu bieten. Ich würde Folgendes nicht empfehlen!
Wenn Sie Ihren Benutzern Zugriff zum Bearbeiten einer bestimmten Datei gewähren möchten, können Sie es mit rnano versuchen :
%staff ALL = /bin/rnano /etc/nginx/sites-available/host
rnano lässt sie nur die angegebene Datei bearbeiten. Das ist wichtig, um zu verhindern, dass ein böswilliger Benutzer einen anderen Upstart-Dienst bearbeitet (z. B. /etc/init.d/urandom ) und Hinzufügen einer Zeile, die service network restart ausführen würde .
Leider habe ich keine Möglichkeit gefunden, rvim einzuschränken ausreichend (der Benutzer kann immer noch jede Datei mit :e öffnen ), also bleiben wir bei nano hängen .
Leider ist es viel schwieriger, Benutzern zu erlauben, mehrere Dateien zu bearbeiten...
Lassen Sie die Benutzer mehrere Dateien bearbeiten (viel schwieriger als es sein sollte)
1. Unsichere Ansätze
Achten Sie auf Platzhalter! Wenn Sie zu viel Flexibilität (oder irgendeine Flexibilität) anbieten, kann diese ausgenutzt werden:
%staff ALL = /bin/rnano /etc/nginx/sites-available/* # UNSAFE!
In diesem Fall wäre ein böswilliger Benutzer in der Lage, jedes andere Upstart-Dienstskript zu bearbeiten und es dann auszuführen:
$ sudo rnano /etc/nginx/sites-available/../../../any/file/on/the/system
(Sudo verhindert tatsächlich . und .. Erweiterung auf den Befehl, aber leider nicht auf die Argumente.)
Ich hatte gehofft, dass so etwas funktionieren könnte, aber es ist immer noch unsicher:
%staff ALL = /bin/rnano /etc/nginx/sites-available/[A-Za-z0-9_-]* # UNSAFE!
Seit sudo bietet derzeit nur glob an Muster, dass * passt zu allem - es ist kein regulärer Ausdruck!
(Bearbeiten:Ich habe darüber nachgedacht, ob Sie vielleicht kommen Sie in Ihrer Situation mit dem Obigen davon, da es keine Unterordner unter sites-available gibt . Wir haben verlangt, dass ein Zeichen nach dem Ordner und /.. abgeglichen wird sollte nach einem Dateinamen fehlschlagen. Dies ist jedoch keine praktikable Lösung, da rnano akzeptiert mehrere Argumente. Und im Allgemeinen wäre dies sowieso immer noch unsicher in einem Ordner, der Unterordner hatte!)
Auch wenn wir keine Unterordner haben und wir alle Zeilen ausschließen, die /../ enthalten , die Regel, die einen * anbietet glob könnte immer noch ausgenutzt werden, weil rnano akzeptiert mehrere Argumente (Durchlauf durch sie auf <C-X> , und das Leerzeichen wird gerne vom * akzeptiert Globus.
$ rnano /etc/nginx/sites-available/legal_file /then/any/file/on/the/system
2. Bis an die Grenzen gehen (auch letztlich unsicher)
Was passiert also, wenn wir Zeilen ablehnen, die Leerzeichen enthalten, oder versuchen, /.. zu erreichen? ? Dann könnte eine letzte praktikable Lösung diese sein:
# I tried hard to make this safe, but in the end I failed again.
# Please don't use this unless you are really smart or really stupid.
%staff ALL = /bin/rnano /etc/nginx/sites-available/*, \
! /bin/rnano */..*, \
! /bin/rnano /etc/nginx/sites-available/, \
! /bin/rnano */., \
! /bin/rnano * *
# CONCLUSION: It is still NOT SAFE if there are any subfolders, due to
# the bug in rnano described below.
Wir akzeptieren alles "unter" dem Ordner, aber wir lehnen auch jeden Anruf an rnano ab wenn /.. oder /. oder weitergegeben werden oder wenn der Ordner direkt als Ziel ausgewählt wird. (Technisch gesehen der /. Ausschluss macht den /.. Ausschluss redundant, aber ich habe beide aus Gründen der Übersichtlichkeit belassen.)
Ich habe den Ordner und den /. gefunden Ausschlüsse wurden benötigt, da der Benutzer sonst auf den Ordner selbst abzielen könnte. Jetzt denken Sie vielleicht an rnano würde blockieren, wenn auf einen Ordner gezeigt würde, aber Sie würden sich irren. Tatsächlich startet meine Version (2.2.6-1ubuntu1) mit einer leichten Warnung und einer leeren Datei, dann auf <C-X> fordert mich auf, einen beliebigen Dateinamen einzugeben zum Speichern, Öffnen eines neuen Angriffsvektors! Nun, zumindest hat es sich geweigert, eine vorhandene Datei zu überschreiben (in dem einen Test, den ich gemacht habe). Wie auch immer, da es keine Möglichkeit gibt, Unterordner mit sudo auf die schwarze Liste zu setzen, müssen wir daraus schließen, dass dieser Ansatz wiederum unsicher ist. Sorry Benutzer!
Diese Entdeckung ließ mich an der Gründlichkeit von nano zweifeln 's "eingeschränkter" Modus. Man sagt, eine Kette ist nur so stark wie ihr schwächstes Glied. Ich fange an, die Kombination von sudo zu spüren Blacklist Black-Magic und rnano möglicherweise nicht sicherer als eine Kette aus Gänseblümchen.
3. Sichere, aber begrenzte Ansätze
Globs sind sehr eingeschränkt – sie erlauben uns nicht, eine Charakterklasse mehrmals zuzuordnen. Sie könnten bieten mehrere Dateibearbeitungen an, wenn alle Ihre Dateinamen die gleiche Länge haben (in diesem Fall host gefolgt von einer einzelnen Ziffer):
%staff ALL = /bin/rnano /etc/nginx/sites-available/host[0-9] # SAFE
Wenn Sie dem Benutzer jedoch Zugriff zum Bearbeiten verschiedener Dateien geben möchten, müssen Sie möglicherweise jede einzelne Datei explizit angeben:
%staff ALL = /bin/rnano /etc/nginx/sites-available/hothost \
/bin/rnano /etc/nginx/sites-available/coldhost \ # SAFE
/bin/rnano /etc/nginx/sites-available/wethost \
/bin/rnano /etc/nginx/sites-available/steves_dodgy_project
Lassen Sie sich nicht in Versuchung führen um einen * zu verwenden an jedem Punkt. Siehe Abschnitt 1. und 2. oben für den Grund! Denken Sie daran:Ein kleiner Ausrutscher kann das gesamte Superuser-Konto und das gesamte System gefährden.
4. Schreiben Sie Ihren eigenen Argumentprüfer (Sicherheit liegt jetzt in Ihrer Verantwortung)
Ich hoffe, sie werden sudo Unterstützung für reguläre Ausdrücke hinzufügen in der Zukunft; Es könnte viele Probleme lösen, wenn es richtig verwendet wird. Aber wir brauchen vielleicht auch die Möglichkeit, die Eigenschaften von Argumenten zu überprüfen (um nur Dateien, nur Ordner oder nur bestimmte Flags zuzulassen).
Aber es gibt eine Alternative, um Flexibilität in sudo zu schaffen. Gib den Schwarzen Peter weiter:
%staff ALL = /root/bin/staffedit *
Dann schreiben Sie Ihren eigenen staffedit Skript oder ausführbares Programm, um zu überprüfen, ob die vom Benutzer übergebenen Argumente zulässig sind, und ihre Anfrage nur auszuführen, wenn dies der Fall ist.
Öffnen Sie zuerst die sudoers-Datei mit sudo visudo . Hinzufügen von user ALL=!/usr/sbin/service wird, IIRC, den service verbieten Befehl für Benutzer user .
Quellen:http://nixcraft.com/showthread.php/15132-Sudo-Exclude-Commands-And-Disable-sudo-su-Bash-Shell
Ich habe die Lösung gefunden.
Ich habe das Terminal geöffnet und mit su - in den Root-Benutzer gewechselt dann habe ich visudo eingetippt zu bearbeiten.
dann habe ich am Ende Zeilen wie
geschriebenuser ALL=!/etc/init.d/NetworkManager restart
user ALL=!/etc/init.d/network restart
Dann habe ich gespeichert &geschlossen und auch neu gestartet.
Wenn ich jetzt als service network restart eingebe oder service NetworkManager restart dann lässt es mich nicht zu und gibt einen Fehler wie
Sorry user is not allowed to execute '/sbin/service NetowkrManager restart' as root on localhost.localdomain
und ähnlich für service network restart Befehl auch.