Kontrolliertes Ausfuehren von Befehlen als root: Unterschied zwischen den Versionen

Aus Linupedia.org
Wechseln zu: Navigation, Suche
(Vor/Nachteile von sudoers augenommen und eine Klarstellung von 'escape Möglichkeit')
(Hinweis bei sudo nicht zu verbieten sondern nur zu erlauben)
Zeile 94: Zeile 94:
 
Diese Definition erlaubt hugo und fritz squid zu starten und zu stoppen.
 
Diese Definition erlaubt hugo und fritz squid zu starten und zu stoppen.
  
 +
=== Wie kann man einen Benutzer alle root Rechte geben mit ein paar Ausnahmen? ===
  
 +
Höchst unsicher und sollte '''nicht''' angewandt werden. Man sollte immer explizit erlauben was ausgeführt werden darf und nicht, was nicht ausgeführt werden darf! Zu leicht übersieht man einen kritischen Befehl oder Parameter oder es wird ein neuer kritischer Parameter mit einer neuen Programmversion eingeführt.
  
 
== mittels zweitem ssh Daemon die Erteilung von root Rechten erlauben ==
 
== mittels zweitem ssh Daemon die Erteilung von root Rechten erlauben ==

Version vom 5. November 2006, 12:20 Uhr

Autor: framp

Den Benutzer root sollte man nur dann benutzen, wenn administrative Dinge auf einem Linux Rechner zu tun sind.( siehe auch Permanent root sein ) Ansonsten sollte man immer als normaler User arbeiten. Als root darf man eben alles - und kann sich so auch unbeabsichtigt sein System zerstören. Ein einziger fehlerhafter oder unüberlegter Befehl, (als User würde er nur einen begrenzten Schaden an den Dateien dieses Users anrichte können) als root abgesetzt, könnte das gesamte System so irreparabel beschädigen, das es nur aus einem Backup oder durch Neuinstallation wieder zu reparieren ist.

Die selbe Regel gilt natürlich auch unter Windows und alle anderen Betriebssystemen, wo man für normale "Arbeit" tunlichst nicht mit Administrator-Kennung angemeldet sein sollte.

Möglichkeiten von Linux Befehle unter andere Userkennung auszuführen

Normalerweise benutzt man bei Linux und anderen UNIXartigen Betriebssystemen dazu su -(eng. substitute user) und erhält damit root Rechte und kann dann auf dem System alles machen, was das Herz begehrt, oder besser, alles was die Administration fordert. Dieses sollte man aber nur bei Administrationaufgaben machen. Für regelmäßige Befehle, die als root abgegeben werden müssen, oder besonders für Aufgaben die anderen Usern überantwortet werden, für die man jedoch Rootrechte benötigt, sind andere Methoden zu bevorzugen:

  1. die Benutzung von sudo
  2. ssh auf localhost und Benutzung von shared keys


der Befehl su

su dieser Befehl erlaubt es eine Shell mit der Userkennung eines anderen Users zu starten. Wird er mit einer der Optionen -, -l, --login gestartet, wir die eine Loginshell gestartet, das bedeutet es wird die komplette Konfiguration wie für ein neues Anmelden dieses Users durchlaufen. Wird kein User angegeben, dann wird der User root angenommen.

su              # startet neue Shell als User root, ohne komplettes Login als root 
su -            # startet neue Shell als User root mit komplettem Login als root
su - user1      # startet neue Shell als User user1 mit kompletter Login als user1

Wird su als normaler User gestartet, dann wird dabei das Passwort des neuen Users benötigt. Wird su als root gestartet, erfolgt keine Passwortabfrage.

Nachteile:

  1. Sämtliche root Rechte werden erhalten
  2. root Passwort wird benötigt
  3. Keine Kontrolle möglich, welcher User root Rechte erlangt hat

Vorteile:

  1. Schnell ausführbar



der Befehl sudo

sudo ist ein Standard bei Linux, mit dem kontrolliert Programmausführungberechtigungen an normale User vergeben werden können. Das können z.B. bestimmte Befehle sein, die dieser User häufiger benötigt, wie z.B. das Starten und stoppen von Daemons. Hat man auf einem System mehrere Administratoren sollte man unbedingt sudo benutzen, denn dann wird immer im Log protokolliert, welcher User sich gerade per sudo root Rechte hat geben lassen. Die Konfiguration erfolgt über eine Konfigurationsdatei /etc/sudoers. Dort kann genau definiert werden wer was als root oder anderer User ausführen darf, auch sind Anpassungen für die Shellkonfiguration für diese Befehle möglich. Für die Änderungen der Konfiguration gibt es ein spezielles Programm visudo. Dieses Programm verhindert grobe Fehler innerhalb der /etc/sudoers.

Nachteile:

  1. Genaue Konfiguration der /etc/sudoers notwendig
  2. /etc/sudoers Konfiguration nicht ganz einfach. Bei Fehlern können Sicherheitslöcher entstehen.

Vorteile:

  1. Genaue Protokollierung wer, wann, welchen Befehl als root abgesetzt hat
  2. Man kann jeden Benutzer oder auch Gruppen authorisieren root befehle abzusetzen
  3. Das root Passwort muß wirklich nur der Sysadmin bzw Stellvertreter kennen.

Folgende Sicherheitsregeln unbedingt beachten

  1. Zentrale Konfigurationsdatei von sudo ist /etc/sudoers immer mit visudo editieren!
  2. Nie su, sudo, visudo oder eine shell oder Programme mit escape Möglichkeiten per sudo freigeben, denn dann hat der Benutzer volle root Rechte! Was ist eine escape Möglichkeit? Wenn ein Programm erlaubt in eine shell Umgebung zu kommen.
  3. Sehr genau auf die Parameter von den Befehlen aufpassen. Ansonsten kann ein simples cat oder chmod ein Sicherheitsloch ins System reissen!
  4. Niemals ein Programm per sudo für einen User aufrufbar machen, wenn er Schreibzugriff darauf hat!

Beispiele

Wie kann man ein Befehl als ein anderer User ausführen

Eintrag in der /etc/sudoers:

hugo   ALL = (fritz) /usr/local/bin/Befehl

Aufruf von hugo:

sudo -u fritz /usr/local/bin/Befehl oder
sudo -u fritz Befehl

hugo wird nach seinem Passwort gefragt und kann dann den Befehl ausführen.

Wie kann man die Passwortabfrage bei sudo abstellen

Eintrag in der /etc/sudoers:

hugo   ALL = (fritz) NOPASSWD: /usr/local/bin/Befehl

Bemerkung Das ist aber nicht ungefährlich: Wenn hugo den Rechner verlässt ohne sich abzumelden, oder der Account von hugo geknackt wird, könnte jeder den Befehl jetzt ohne Passwortabfrage ausführen. Dieses sollte also nur für Batchjobs etc. gemacht werden.

Wie werden Parameter verboten

Eintrag in der /etc/sudoers:

hugo   ALL = (fritz) /usr/local/bin/Befehl ""

Durch Anhängen von "" am Ende der Zeile ist es jetzt nicht mehr möglich, dem Befehl noch irgendwelche Parameter hinzuzufügen.

Wie kann man Passwortänderungen deligieren

Eintrag in der /etc/sudoers:

hugo   ALL = (root) /usr/bin/passwd alpha, /usr/bin/passwd beta

Damit kann jetzt hugo die Passwörter von alpha und beta ändern. Wenn man eine Gruppe von Usern hat und deren UserIDs systematisch definiert sind, geht es noch einfacher:

Eintrag in der /etc/sudoers:

hugo   ALL = (root) /usr/bin/passwd gruppe[0-9][0-9]

erlaubt hugo, die Passwoerter aller userIDs der Form gruppe00, gruppe01, etc zu ändern.

Wie kann man Daemons starten und stoppen lassen

Eintrag in der /etc/sudoers:

User_Alias    SUBADMIN=hugo, fritz
Cmd_Alias   DAEMON=/usr/sbin/rcsquid start,
                    /usr/sbin/rcsquid stop,
                    /usr/sbin/rcsquid restart
SUBADMIN ALL = (ALL) DAEMON

Diese Definition erlaubt hugo und fritz squid zu starten und zu stoppen.

Wie kann man einen Benutzer alle root Rechte geben mit ein paar Ausnahmen?

Höchst unsicher und sollte nicht angewandt werden. Man sollte immer explizit erlauben was ausgeführt werden darf und nicht, was nicht ausgeführt werden darf! Zu leicht übersieht man einen kritischen Befehl oder Parameter oder es wird ein neuer kritischer Parameter mit einer neuen Programmversion eingeführt.

mittels zweitem ssh Daemon die Erteilung von root Rechten erlauben

Bemerkung: Diese Methode ist höchst unsicher und sollte nur beschränkt angewandt werden.

ssh kann man auch auf localhost anwenden und dadurch gezielt Usern die Ausführung von root Befehlen ermöglichen. Der Nachteil gegenüber sudo ist, dass keine Protokollierung der ausgeführten Befehle stattfindet. Außerdem muss der root login dazu in dem sshd daemon erlaubt sein, was jedoch im Normalfall ausgeschaltet sein sollte. Deshalb sollte man diese dann nicht über den normalen ssh-Dienst laufen lassen, sondern extra dafür einen zweiten sshd daemon auf einem freien Port aufsetzen (im Beispiel 4711), der dann seine eigene Konfigurationsdatei abgestimmt auf diese Funktion bekommt:

Konfiguration für einen extra ssh-Dienst zur Erteilung von Rootrechten:

  1. 'Port 4711
  2. PermitRootLogin without-password
  3. PubKeyAuthentication yes
    Rootlogin ohne passwort und NUR pubkey authentication
  4. Aufnahme von from="127.0.0.1" und command="..." in authorized_keys so dass die Befehle nur vom lokalen System aufgerufen werden können
  5. Kopieren der public keys der User, die Befehle per ssh ausführen können sollen in ~/root/.ssh/authorized_keys und Einschraenkung der Berechtigung mit
    command="/usr/sbin/rcsquid start". Dieses muss leider für jeden Befehl erlaubten getan werden.
    Alternative: (siehe weiter unten)
    Wichtig: Keine Zeile ohne command in authorized_keys stellen denn sonst hat der user uneingeschränkten root Zugriff!
  6. Schutz des sshd ports 4711 mit iptables vor externem Zugriff
  7. Ein kurzes Script erstellen, mit dem man einfach die Befehle per local ssh aufrufen kann
ssh -p 4711 -l root localhost $@


Beispiel: ~/root/.ssh/authorized_keys:

command="/usr/sbin/rcsquid start" ssh-rsa AAAAB3NzaC1 ....


Wie mehrere Befehle einfacher zulassen?

Ein Script erstellen, welches in einem Switch die Befehle enthält, die ausgeführt werden dürfen. Dieses Script (z.B. /usr/local/sbin/ssh-for-hugo) in die authorized_keys aufnehmen, also

command="/usr/local/sbin/ssh-for-hugo $SSH_ORIGINAL_COMMAND" ssh-rsa AAAAB3NzaC1 ....

Das Script sieht dann etwa so aus:

 case "$1" in
    rcsquid-start)
          /usr/sbin/rcsquid start
          ;;
    rcsquid-stop)
          /usr/sbin/rcsquid stop
          ;;
    rcsquid-restart)
        /usr/sbin/rcsquid restart
          ;;
    *)
       echo "Illegal request rejected" 1>&2
       exit 1
    ;;
 esac


Als Vorlage zu diesem Thema diente Kontrolliertes Ausführen von Programmen mit Rootkennung Autor: framp, dringend empfohlen als Nachschlagewerk bei Unklarheiten mit diesem Beitrag


  • eingefügt von --Yehudi 23:13, 30. Aug 2006 (CEST)
  • komplett überarbeitet Robi 02:05, 29. Okt 2006 (CEST)