was will sudo?

[MacAlzenau]

Ich denke, ihr redet ein wenig aneinander vorbei.
Mangels Detailwissen habe ich das Ganze eher überflogen als studiert, aber es geht Goglo wohl nicht darum, daß irgendein fremder Drittuser in der sudoer-Liste steht, sondern daß sich der Admin, wenn er aus Sicherheitsgründen als Normaluser unterwegs ist, sich dennoch in der sudoer-Liste eintragen kann, ohne daß die Sicherheit nach außen dadurch leidet.
Während MacMark und Rastafari wohl davon reden, daß man unbedarften Familienmitglieder et cetera mit diesem Eintrag natürlich alle Zerstörungsrechte gäbe.

 

[MacMark]

Wenn der Normaluser sudo-berechtigt ist, dann ist die "Normal-User-Sicherheit" nicht mehr existent.

Auch "nach außen": Das Erste, was ein Payload machen wird, ist eine Wörterbuchattacke auf sudo, bzw .mit gefälschtem Dialog sich das Paßwort direkt geben lassen und dann sudo aufrufen. Das ist normalerweise wirkungslos. Aber dank unserem Spezialisten hier, ist der Rechner dann Toast auch durch diesen "Normaluser".

Wenn er sudo braucht, soll er sich als Admin anmelden: Per GUI oder per su. Wer dazu zu faul ist, ist selbst schuld. Vor allem, wenn er stattdessen lieber die User-Hierarchie versaut.

 

[MacAlzenau]

Wenn der Normaluser sudo-berechtigt ist, dann ist die "Normal-User-Sicherheit" nicht mehr existent.

Das heisst, ich bin völlig unsicher unterwegs, weil ich zwar als Normaluser angemeldet bin, aber mein Admin-Passwort kenne (ich bin ja nicht schizophren) und mich ja problemlos über su zum Sudoberechtigten machen kann?
Das ist doch nur ein einziger Schritt mehr, und das Passwort muß ich so oder so wissen für sudo.

 

[MacMark]

Wenn der Normaluser mit seinem "Tip" in der sudoers-Liste steht, ist das de facto ein Admin und kein Normaluser mehr.

 

[Cathul]

Das heisst, ich bin völlig unsicher unterwegs, weil ich zwar als Normaluser angemeldet bin, aber mein Admin-Passwort kenne (ich bin ja nicht schizophren) und mich ja problemlos über su zum Sudoberechtigten machen kann?
Das ist doch nur ein einziger Schritt mehr, und das Passwort muß ich so oder so wissen für sudo.

Wenn der normale Benutzer in der /etc/sudoers steht ist das ein Schritt weniger, richtig.
Nämlich der Schritt "su - admin" fällt weg und dem normalen Benutzer reicht ein simples "sudo" um auf das komplette System mit root-Rechten zugreifen zu können.
Da normale Benutzer sehr häufig die Angewohnheit haben, unsichere Passwörter zu verwenden, ist die Wahrscheinlichkeit Opfer eines Dictionary-Attacks zu werden relativ hoch (wenn solch ein Angriff gefahren wird).

Daher ist die Empfehlung den normalen Benutzer in die /etc/sudoers aufzunehmen denkbar ungeeignet.

Das Entwickeln und kompilieren von Applikationen kann normalerweise jeder normale Benutzer auf einem UNIX durchführen, da ist es egal ob Linux, BSD, AIX, HP-UX oder halt Mac OSX. Man muss halt nur darauf achten, dass der Quelltext im eigenen Homeverzeichnis liegt, damit man entsprechende Berechtigungen hat.

Die Installation, und nur diese, führt man dann als Admin oder root (per sudo) aus.

 

[MacAlzenau]

Da normale Benutzer sehr häufig die Angewohnheit haben, unsichere Passwörter zu verwenden, ist die Wahrscheinlichkeit Opfer eines Dictionary-Attacks zu werden relativ hoch (wenn solch ein Angriff gefahren wird).

Daher ist die Empfehlung den normalen Benutzer in die /etc/sudoers aufzunehmen denkbar ungeeignet.

Warum soll ich, wenn ich ohne Adminrechte arbeite, also als Normalbenutzer, unsicherere Passwörter nehmen als wenn ich als Admin arbeite?
Ihr scheint immer davon auszugehen, daß jeder Benutzer auch eine physisch andere Person ist. Darum geht es aber, jedenfalls soweit ich den attackierten Vorschlag verstehe, garnicht.

 

[Cathul]

ich bin aber nicht in der Admin-Gruppe. Was muss ich dann eingeben?

$ su - admin
Passwort: *******
# cd $PFAD-ZUM-QUELLCODE
# sudo make install
Passwort: *******

ls -Ole /var/tmp sagt folgendes:

Im Listing sind die Berechtigungen für das aktuelle Verzeichnis nicht sichtbar.
Mach mal folgendes:

ls -aOle

 

[Cathul]

Warum soll ich, wenn ich ohne Adminrechte arbeite, also als Normalbenutzer, unsicherere Passwörter nehmen als wenn ich als Admin arbeite?

Erstmal sugeriert das keiner, zweitens ist es im echten Leben so, dass Otto-Normal-User ein Passwort hat wie "Zuckerbärchen" oder ähnlich aus Sicherheitssicht schlimmes.

Ihr scheint immer davon auszugehen, daß jeder Benutzer auch eine physisch andere Person ist. Darum geht es aber, jedenfalls soweit ich den attackierten Vorschlag verstehe, garnicht.

Beim attackierten Vorschlag geht es darum, dass hier das Sicherheitsmodell von OSX unnötigerweise enorm aufgeweicht wird.

 

[MacAlzenau]

Erstmal sugeriert das keiner, zweitens ist es im echten Leben so, dass Otto-Normal-User ein Passwort hat wie "Zuckerbärchen" oder ähnlich aus Sicherheitssicht schlimmes.

Doch, es wird einfach unterstellt, daß grundsätzlich Normaluser und Admin sich unterschiedlich verhalten - und das stimmt eben allenfalls, wenn es unterschiedliche Menschen sind. Was aber nicht sein muß, wohl in den meisten Fällen auch nicht ist.

 

[Cathul]

Doch, es wird einfach unterstellt, daß grundsätzlich Normaluser und Admin sich unterschiedlich verhalten - und das stimmt eben allenfalls, wenn es unterschiedliche Menschen sind. Was aber nicht sein muß, wohl in den meisten Fällen auch nicht ist.

Nochmal:

Wenn ich das

$ su - admin

überflüssig mache und in der /etc/sudoers wie vorgeschlagen:

foobar    ALL=(ALL) ALL

eintrage, passiert beim Aufrufen des folgenden Kommandos, und das kann schon durch einen kurzen Flüchtigkeitsfehler passieren, wohl was?

$ sudo rm -rf /*
Passwort: *******

Würde der normale Benutzer nicht in der /etc/sudoers stehen würde wohl was passieren? Genau, gar nix, da er dieses Kommando nicht ausführen dürfte.
Und jetzt überleg mal was professionell geschriebene Schadprogramme machen könnten, wenn Sie als normaler Benutzer gestartet per Dictionary-Attack das oftmals allzu leichte Passwort erraten haben wenn der normale Benutzer per sudo alles, und die vorgeschlagene Konfiguration erlaubt tatsächlich _alles_, machen dürften?

 

[MacAlzenau]

Also erstmal: ich habe jetzt geschnallt, daß du mit Otto-Normal-User nicht den Unterschied Admin/Normaluser meintest (beim Zuckerbärchen-Passwort), sondern den üblichen Benutzer, egal ob er als Admin arbeitet oder als Nicht-Admin.
Da magst du recht haben, aber das hat natürlich nur peripher mit dem Sicherheitskonzept zu tun, wenn Benutzer kein Passwort vergeben oder so ein einfaches.

Bei dem genannten Beispiel sehe ich auch nur eine zweite Ebene, keinen grundsätzlichen Unterschied. Ich muß mein Passwort eingeben, das ist das Entscheidende. Ohne auf der sudoer-Liste zu stehen, muß ich eben zweimal ein Passwort eingeben. Wenn ich da beidemal ein Primitivpasswort habe, ist es zwar zugegebenermassen dennoch sicherer, aber Leuten mit solchen Passwörtern darf man auch unterstellen, ihren Admn-Account "Admin" zu nennen und dann beidemale das gleiche Passwort zu verwenden.

Ich gehe wie gesagt davon aus, daß wir hier im Forum über Personal Computer reden, wo der Normalnutzer fast immer auch der Besitzer ist, also sein Adminpasswort sowieso kennt. Nebenbei: Irgendeinen Sinn wird es ja wohl sowieso haben, wenn UNIX und OS X überhaupt die Möglichkeit anbietet, Nicht-Admins in diese Liste eintragen zu lassen.

 

[MacMark]

In UNIX-Konfigurationsdateien kannst Du alles eintragen. Das macht jedoch noch lange nicht alles sinnvoll. Insbesondere kann eine Fehlkonfiguration (wie hier) das System kompromittieren.

Der "Tip" macht den Normaluser faktisch zum Admin. Damit ist das Konzept "Sicherheit durch Normaluser-Betrieb" kaputt! Das hat nicht am Rande, sondern integral mit dem Sicherheitskonzept zu tun!

 

[Cathul]

Also erstmal: ich habe jetzt geschnallt, daß du mit Otto-Normal-User nicht den Unterschied Admin/Normaluser meintest (beim Zuckerbärchen-Passwort), sondern den üblichen Benutzer, egal ob er als Admin arbeitet oder als Nicht-Admin.
Da magst du recht haben, aber das hat natürlich nur peripher mit dem Sicherheitskonzept zu tun, wenn Benutzer kein Passwort vergeben oder so ein einfaches.

Bei dem genannten Beispiel sehe ich auch nur eine zweite Ebene, keinen grundsätzlichen Unterschied. Ich muß mein Passwort eingeben, das ist das Entscheidende. Ohne auf der sudoer-Liste zu stehen, muß ich eben zweimal ein Passwort eingeben. Wenn ich da beidemal ein Primitivpasswort habe, ist es zwar zugegebenermassen dennoch sicherer, aber Leuten mit solchen Passwörtern darf man auch unterstellen, ihren Admn-Account "Admin" zu nennen und dann beidemale das gleiche Passwort zu verwenden.

Bei der Reflektierung der ganzen Problematik fällt mir auf, dass die meisten Benutzer eh mit einem Admin-Account unterwegs sein dürften, nämlich dem Account, der nach der ersten Inbetriebname des Rechners angelegt und zunächst automatisch eingeloggt wird.
An dieser Stelle dürftest Du Recht haben.

Ich gehe wie gesagt davon aus, daß wir hier im Forum über Personal Computer reden, wo der Normalnutzer fast immer auch der Besitzer ist, also sein Adminpasswort sowieso kennt. Nebenbei: Irgendeinen Sinn wird es ja wohl sowieso haben, wenn UNIX und OS X überhaupt die Möglichkeit anbietet, Nicht-Admins in diese Liste eintragen zu lassen.

Sudo wurde geschrieben, damit man manche Kommandos ausführen kann, aber noch lange nicht alle. Und ja, natürlich kann man einem normalen Benutzer alle Berechtigungen geben, aber Sinn macht das deswegen noch lange nicht. Nicht umsonst ist das Kommando "visudo" auf normalen UNIXen/Linux auch nicht durch einen normalen Benutzer ausführbar, sondern nur durch einen mit der Systempflege beauftragten Benutzeraccount.
Und normale Personal Computer... naja... die UNIX Programme kommen ursprünglich aus einer Welt, in der der Multiuser-Betrieb die Regel und nicht die Ausnahme ist. Programme aus dieser Welt haben normalerweise nicht das Personal Computer Bedienungsparadigma, zumindest nicht auf der Ebene, auf der man sudo bedient.

 

[Goglo]

Ich sehe schon, wir kommen hier nicht weiter. Es wird immer noch argumentiert, daß das doof ist, weil's angeblich irgendwer auf einem Mac so nicht vorgesehen hat. Bzw. daß alleinig die Zugehörigkeit zur Admingruppe das seligmachende Kennzeichen eines Admins ist. Hier geht's also nur ums Prinzip. Damit man das nicht so offen sagen muß, wird nun mit mehr oder weniger sicheren Passwörtern argumentiert oder der Entwickler mit dem DAU gleich-, oder mir unterstellt, ich wolle das mit allen Benutzern machen.

Nochmal die Ausgangssituation: $Entwickler muß ab und an mal ein make install laufen lassen. Deshalb hat er zusätzlich zu seinem Account ein <admin>-Passwort.

Plan a) sudo <admin>; sudo make install; exit.
Plan b) In die sudoers mit seinem normalen User, dann reicht ein einfaches sudo make install.
Plan c) Sein user wird Mitglied der Administratorengruppe
a) ist gerade bei gegen Wörterbuchattacken resistenten Passwort mühsam.
b) ist vielleicht so nicht vorgesehen und deshalb bäh.
c) Als Admin permanent zu arbeiten wird von niemanden ernsthaft empfohlen. Unter OS X geht's aber eher als unter anderen UNIXen oder Windows. Scheint aber hier die einzig akzeptable Alternative zu a) zu sein.

Ich sehe b) immer noch als ganz guten Mittelweg zwischen a) und c): Der Mensch ist nicht permanent Admin, kommt aber wenn er will, schnell dahin. In der GUI ist der Mensch weiterhin als normaler User unterwegs, was das Risiko sich was Böses einzufangen, auf niedrigerem Level hält, als das bei c) der Fall ist.
Diese Lösung ist sicherlich nicht für Lieschen Müller und schon gar nicht für alle User gedacht, wie hier ja totschlagmäßig dagegen argumentiert wird. Übrigens wird ein normales Lieschen Müller aller Wahrscheinlichkeit der Gruppe der Administratoren angehören, da sie sich bestimmt als ersten Benutzer bei der Installation angelegt hat und den Tip mit dem separaten Admin gar nicht kennt.

 

[Goglo]

In UNIX-Konfigurationsdateien kannst Du alles eintragen. Das macht jedoch noch lange nicht alles sinnvoll. Insbesondere kann eine Fehlkonfiguration (wie hier) das System kompromittieren.

Das System wird nicht dadurch kompromittiert, daß einem zusätzlicher Benutzer, der nicht Mitglied der Administratorengruppe ist, das Recht eingeräumt wird, den Rechner zu verwalten. Kompromittieren in dem Sinne wäre ein SUID-Shellscript, welches root gehört und jedem eine admin-shell aufmacht. Es ist immer noch ein *einzelner* User, dem *gezielt* ein gesondertes Recht eingeräumt wird. Nicht Hinz und Kunz können sudo, sondern nur der eine. Und ob ich dem nun die Admingruppe zuordne oder ihn in die sudoers packe, ist lediglich ein anderer Weg zum selben Ziel.

 

[Cathul]

Ich sehe schon, wir kommen hier nicht weiter. Es wird immer noch argumentiert, daß das doof ist, weil's angeblich irgendwer auf einem Mac so nicht vorgesehen hat. Bzw. daß alleinig die Zugehörigkeit zur Admingruppe das seligmachende Kennzeichen eines Admins ist. Hier geht's also nur ums Prinzip. Damit man das nicht so offen sagen muß, wird nun mit mehr oder weniger sicheren Passwörtern argumentiert oder der Entwickler mit dem DAU gleich-, oder mir unterstellt, ich wolle das mit allen Benutzern machen.

Ich persönlich unterstelle lediglich, dass ein

foobar ALL=(ALL) ALL

nicht gemacht werden sollte.
Grenzt man das sudo im aktuellen Fall auf "make" und die entsprechenden Optionen ein, kann halt nur "make" mit den entsprechenden Optionen per sudo gestartet werden.

Cmd_Alias MAKE = /usr/bin/make, /usr/bin/make install, /usr/bin/make all, ...
foobar MAKE=ALL

Mehr braucht ein Entwickler mit Sicherheit nicht.

Zusätzlich halte ich es für eine gute Idee, den eigentlichen sudo Befehl in ein Shellscript zu kapseln, damit das Passwort nicht gespeichert, sondern bei jedem Aufruf erneut abgefragt wird. Dazu wird das sudo-Kommando erst nach "sudo.orig" verschoben und ein neues Shellscript mit Namen sudo im selben Pfad wie "sudo.orig" mit dem folgenden Inhalt angelegt (Pseudocode, Pfad muss angepasst werden!):

#!/bin/sh
/PFAD/ZU/sudo.orig -k

 

[Goglo]

Sudo wurde geschrieben, damit man manche Kommandos ausführen kann, aber noch lange nicht alle. Und ja, natürlich kann man einem normalen Benutzer alle Berechtigungen geben, aber Sinn macht das deswegen noch lange nicht. Nicht umsonst ist das Kommando "visudo" auf normalen UNIXen/Linux auch nicht durch einen normalen Benutzer ausführbar, sondern nur durch einen mit der Systempflege beauftragten Benutzeraccount.

sudo wurde geschrieben, damit der root-account besser geschützt werden kann. Früher war der Admin immer "root" und somit war für Attacken von außen schonmal der Username bekannt. Aus dem selben Grund sollte der Admin auch nicht "admin" oder "Administrator" heißen. Heutzutage ist "root" kein user mehr, der sich einloggen kann. Damit man aber trotzdem administrieren kann, brauchts irgendwie die Sonderrechte. Ein erster Schritt war root nur über "su" zuzulassen. Stand die shell aber offen 'rum, war das auch nicht gut. Also brauchts ein Programm, welches ggf. nochmal ein Passwort abfragt und dann root-Rechte für einzelne Benutzer zuläßt und noch ein bisschen mitloggt, wer wann was gemacht hat. Also andersrum als das UNIX-Sicherheitskonzept: Nicht alle werden per su der User, der alles Besondere darf, sondern jedem kann das Besondere gezielt erlaubt werden. Daß die Konfigurationsdatei natürlich nicht von jedem gelesen - und schon gar nicht geschrieben werden kann, versteht sich in dem Zusammenhang von selbst. Sonst könnte sich ja jeder Bock zum Gärtner machen.

Übrigens kann man mit der sudoers wesentlich feiner die Administratorenrechte einstellen, als das pauschal mit der OS X-schen Administratorengruppe der Fall ist.

 

[Cathul]

Goglo, das alles ist mir durchaus bekannt. Dennoch ist es Unsinn, einem Entwickler, der nur die Berechtigung für z.B. "make install" braucht direkt alle Rechte zu geben. _Das_ ist das was an Deiner Idee kritisiert wird.

 

[Goglo]

Ich persönlich unterstelle lediglich, dass ein

foobar ALL=(ALL) ALL

nicht gemacht werden sollte.
Grenzt man das sudo im aktuellen Fall auf "make" und die entsprechenden Optionen ein, kann halt nur "make" mit den entsprechenden Optionen per sudo gestartet werden.

Sicherlich eine gute Idee. Es war mir nur zu anstrengend, das alles auszubaldowern. Ich vermute aber auch, daß eine Aktion im Makefile, welches nur eine shell aufmacht dem User eine root-shell präsentiert. (Ausprobiert habe ich gerade mal "sudo visudo" und dann sh<enter>" Ich bin aber auch der oben zitierte Admin)

Zusätzlich halte ich es für eine gute Idee, den eigentlichen sudo Befehl in ein Shellscript zu kapseln, damit das Passwort nicht gespeichert, sondern bei jedem Aufruf erneut abgefragt wird.

Das würde ich unter "security by obscurity" ablegen, denn sudo.orig muß weiterhin ausführbar bleiben und kann auch direkt aufgerufen werden. $PATH erweitern oder ein persönlicher alias regelt. Wenn's aber unbedingt sein muß, wäre ein "alias sudo=sudo -k $*" in der /etc/bashrc der einfachere Weg.

 

[Cathul]

Sicherlich eine gute Idee. Es war mir nur zu anstrengend, das alles auszubaldowern. Ich vermute aber auch, daß eine Aktion im Makefile, welches nur eine shell aufmacht dem User eine root-shell präsentiert. (Ausprobiert habe ich gerade mal "sudo visudo" und dann sh<enter>" Ich bin aber auch der oben zitierte Admin)

Kann gut sein, dennoch werden die Angriffswege erstmal deutlich eingeschränkt und der potentielle Angreifer muss erstmal nachschauen welche Befehle er überhaupt ausführen darf. Dafür entsprechende Routinen zu schreiben, die dann genau für die erlaubten Befehle entsprechende Exploits bereit stellen, halte ich für zu aufwändig, da es hier keinen einfachen Standardweg gibt. Was bei dem einen Client geht, muss beim nächsten nicht funktionieren.

Das würde ich unter "security by obscurity" ablegen, denn sudo.orig muß weiterhin ausführbar bleiben und kann auch direkt aufgerufen werden. $PATH erweitern oder ein persönlicher alias regelt. Wenn's aber unbedingt sein muß, wäre ein "alias sudo=sudo -k $*" in der /etc/bashrc der einfachere Weg.

Über Aliase kann man das ganze natürlich auch realisieren. Das hätte den weiteren Vorteil, dass das Festplattendienstprogramm beim Rechte-reparieren nicht meckert.