Root Benutzer dauerhaft verwenden

  • Hey!

    Ich bin gerade dabei einen Dateiserver am Raspberry Pi 2 zu machen. Derzeit arbeite ich immer im Benutzer root und der Benutzer pi besteht jedoch noch abr wird nicht genutzt. Jetzt will ich den Benutzer pi löschen und nur mehr am Benutzer root arbeiten. Da ich ihn direkt ins Netz hängen will wollte ich euch fragen wie es mit der Sicherheit aussieht bezüglich dem Benutzer root. Und was kann man noch für die Sicherheit am raspberry machen wenn man ihn direkt ins Netz hängt.

    Danke schon mal für all eure Antworten! :danke_ATDE:

    Für nützliche Literatur zum Thema Informatik bin ich immer erfreut!
    Tipps für die Literatur in eine PN packen und senden :rolleyes:

  • Das was dunklesToast schrieb nur in einem Befehl:

    Code
    sudo userdel -r BENUTZER


    Da ich ihn direkt ins Netz hängen will wollte ich euch fragen wie es mit der Sicherheit aussieht bezüglich dem Benutzer root. Und was kann man noch für die Sicherheit am raspberry machen wenn man ihn direkt ins Netz hängt.

    Dann solltest du unbedingt mit dem Benutzer pi weiter arbeiten und das Password vom root Benutzer löschen!

    Code
    sudo passwd -d root

  • bevor du den user "pi" löscht solltest du dir vllt nochmal http://www.lpi-certification.de/wiki/opensuse/Permanent_root_sein ansehen und dich fragen ob es wirklich sinnvoll ist nur als root zu arbeiten.
    jedes programm und auch jedes script wird dann mit root-rechten ausgeführt. Webserver, ftp-server und auch andere Dienste sollten alle ihren eigenen Benutzer haben.

    Ok danke dieser Artikel war sehr hilfreich, der Link war auch sehr interessant! Danke
    Automatisch zusammengefügt:


    Das was dunklesToast schrieb nur in einem Befehl:

    Code
    sudo userdel -r BENUTZER


    Dann solltest du unbedingt mit dem Benutzer pi weiter arbeiten und das Password vom root Benutzer löschen!

    Code
    sudo passwd -d root

    Ok danke für den Tipp! werde ihn mir merken und anwenden!

    Für nützliche Literatur zum Thema Informatik bin ich immer erfreut!
    Tipps für die Literatur in eine PN packen und senden :rolleyes:

    Einmal editiert, zuletzt von Orban (19. Dezember 2015 um 21:27)

  • Ständig als root zu arbeiten ist nicht zu empfehlen. Links dazu sind ja schon gepostet worden.

    Keine Ahnung was Du da genau freigeben willst. Dateiserver .. heisst das Windows und Samba :-/ Wenn ja lass es sein!!!

    Beschäftige Dich mit vpn und richte das ein. Dann bist Du auf der sicheren Seite. Ansonsten lass die Finger davon - da ist schneller einer in Deinem lokalen Netz als Dir lieb ist !

  • ok danke für die ganzen antworten! Falls noch jemandem Antworten einfallen gerne hier drunter ;;)
    nochmals danke für eure Hilfe

    PS: Ich werde einfach den Benutzer pi umbenennen und den neuen mit sudo rechten ausustatten. :danke_ATDE:
    oder man nimmt einfach "sudo su" und loggt sich dannach wieder aus, so das man keinen fixen "root" account habe auf dem man sich per ssh einloggen kann ;)

    Für nützliche Literatur zum Thema Informatik bin ich immer erfreut!
    Tipps für die Literatur in eine PN packen und senden :rolleyes:

    Einmal editiert, zuletzt von Orban (19. Dezember 2015 um 22:19)

  • Nein selbstverständlich ist pi ein ganz normaler 08/15 Benutzer. Allerdings hat pi standardmäßig zumindest bei Raspbian uneingeschränkten Zugriff über sudo, ohne Password Abfrage - das ist auch ein Sicherheitsproblem aber naja... Wir wissen nicht was der TE genau vor hat, Forumsuche könnte er aber auch mal nutzen :fies:

  • PS: Ich werde einfach den Benutzer pi umbenennen und den neuen mit sudo rechten ausustatten. :danke_ATDE:
    oder man nimmt einfach "sudo su" und loggt sich dannach wieder aus, so das man keinen fixen "root" account habe auf dem man sich per ssh einloggen kann


    Wenn du es sicher haben willst, solltest du als allererstes "root" ein sicheres Passwort vergeben. Als nächstes unbedingt den User Pi löschen, weil der wegen des Images schon Rechte voreingestellt hat. Dann richtest du einen ganz normalen User ein, der über keinerlei Extra-Rechte verfügt. Das kann der Autologin-User werden/sein oder der mit dem du dich anmeldest. Als nächstes deinstallierst du das Paket "sudo", welches für Administrationsaufgaben völlig überflüssig ist und nur ein überflüssiges Sicherheitsrisiko darstellt, falls Fehler in der sudoers gemacht wurden. Als letztes verbietest du noch den root-login in der sshd und änderst auch sofort den port von 22 auf irgendwas hohes ... um die. 45000 oder so.

    Und dann empfehle ich dir, dich mit den Policies zu beschäftigen, um explizite Berechtigungen zu setzen. Das ist nicht so kompliziert, wie es am Anfang scheint. Aber User pi, "sudo" und permanente root-Anmeldung solltest du tunlichst vergessen.... oder alternativ aufhören, über Sicherheit nachzudenken ....

    Jm2c

    Einmal editiert, zuletzt von WinterUnit16246 (20. Dezember 2015 um 00:30)

  • Wenn du es sicher haben willst, solltest du als allererstes "root" ein sicheres Passwort vergeben. Als nächstes unbedingt den User Pi löschen, weil der wegen des Images schon Rechte voreingestellt hat.

    Das ist unnötig. Der pi Benutzer kann bestehen bleiben, er brauch nur über visudo die Rechte ohne Password Abfrage entfernen.

    und änderst auch sofort den port von 22 auf irgendwas hohes ... um die. 45000 oder so.

    Das brauch er ebenfalls nicht da er nur den externen Port von der Portweiterleitung anders setzen brauch. Der Port in der sshd_config kann so bleiben.


    Man muss sich halt schon ein gewisses Sicherheitskonzept überlegen - was aber davon abhängig ist WAS man machen möchte. Die Aussage "direkt ans Netz hängen" ist sehr dehnbar und könnte auch nur den Webserver betreffen - wissen wir nicht, rum raten ist unnütz.

    Eine Forumsuche nach "Absichern" würde schon einiges zu Tage fördern.

  • Das ist unnötig.

    Weil das Statement so schön markant ist, zitiere ich es einfach mal aus dem Zusammenhang gerissen....... :^^:

    [font="DejaVu Serif, serif"]Unnötig ist allein die Tatsache, feststellen zu müssen, wie leichtsinnig hier mit Rechten für ein System mit Web-Zugang vor dem Hintergrund „unwissender Anwender“ umgegangen wird und dabei im Nebeneffekt die notwendige Sicherheit behindert wird. Ich halte es aber überhaupt nicht für unnötig, den Anwender vor seiner eigenen Unwissenheit zu schützen.[/font]

    [font="DejaVu Serif, serif"]Dem Linux-Beginner resp. Windows-Umsteiger ist in keinster Weise bewusst, dass „sudo“ ein 25 Jahres altes Relikt aus der Zeit der Linux-Server ohne Desktop-Environment ist. Er weiß nicht, dass es allein dafür gedacht war, einzelnen unprivilegierten Benutzen explizite Sonderrechte zu vergeben, um ihnen eben nicht das root-PWD geben zu müssen. Diese Situation ist auf seinem Rechner aber gar nicht gegeben. [/font]

    [font="DejaVu Serif, serif"]Diesem Anwender ist nicht bewusst, [font="DejaVu Sans, sans-serif"]dass[/font] jedes sudo-Command in seiner persönlichen History gespeichert wird und in seinem Profil über Tage und Wochen (ggf. auch unberechtigt) eingesehen werden kann.[/font]

    [font="DejaVu Serif, serif"]Ihm ist nicht bewusst, dass jedes sudo-Cmd einen 5-minütigen PWD-Keep beinhaltet, in dem das System quasi „offen“ ist. [/font]

    [font="DejaVu Serif, serif"]Ihm ist auch nicht bewusst, dass „sudo“ für die heute übliche private Ein-Personen-Systemadministration im Grunde genommen so überflüssig ist, wie ein Kropf und nicht anderes als ein Sicherheitsrisiko darstellt. „sudo“ ist der von U-Nation perfekt etablierte Missbrauch von Privilegien, um es den Windows-Admin-Rechten unter Ausschaltung der UAC nachzutun. Nur wird dabei allzugerne vergessen, das Windows mit der standardmäßig aktivierten Firewall und den fast immer installierten AV-Tools doch geringfügig besser aufgestellt ist. [/font]

    [font="DejaVu Serif, serif"]Ihm ist vermutlich auch nicht bewusst, dass Linux doch ein wenig anders ist als Windows und im Gegensatz zu Windows so gut wie über keine Abwehrkräfte verfügt, wenn man das Linux-Konzept verlässt und den Umgang so handhabt, wie man das unter Windows gewohnt ist. Warum sollte er auch eine andere Erwartungshaltung haben, wenn doch überall Linux als das sicherere OS propagiert wird? Das es das nur ist, solange er sich an die strengen Spielregeln hält, weiß er nicht. Darüber hinaus hat er keine Chance festzustellen, ob und wann das System kompromittiert wurde, wenn es kompromittiert wurde…. und das er selber das erst ermöglicht hat. [/font]

    [font="DejaVu Serif, serif"]Ihm ist nicht bekannt, dass die sudoers mit dem erfreulichen Effekt und dem großen Komfort von[/font] NOPASSWD[font="DejaVu Serif, serif"] die so ziemlich größte vorstellbare Sicherheitslücke im System darstellt…. wie auch…?.... er freut sich ja darüber, wie einfach das alles zu handhaben ist und hat auch noch ein gutes Sicherheitsgefühl dabei. [/font]

    [font="DejaVu Serif, serif"]Ihm ist auch nicht bewusst, dass man die sudo-Funktionalität mit einem 6-zeiler-Bashscript mit Hilfe der Policies einfach emulieren kann, wenn man unbedingt drauf besteht. Das hat zumindest den Vorteil, dass man es anders als „sudo“ (wonach jeder Depp [/font][font="DejaVu Serif, serif"]natürlich [/font][font="DejaVu Serif, serif"]sofort sucht) nennen kann und das man den 5-Min-Passwd-Keep abschalten kann. Ich bin aber der Meinung, er soll besser ganz auf diesen Mist verzichten, [/font][font="DejaVu Serif, serif"]das Paket „sudo“[/font] [font="DejaVu Serif, serif"]deinstallieren [/font][font="DejaVu Serif, serif"]und sich bei Bedarf als root mit einem ordentlichen Password anmelden, in diesem gesicherten Account alle Administrationstätigkeiten durchführen und [/font][font="DejaVu Serif, serif"]sich [/font][font="DejaVu Serif, serif"]nach Erledigung konsequent wieder abmelden. Auf einem von einer Person privat geführten System gibt es keinen einzigen vernünftigen Grund [/font][font="DejaVu Serif, serif"]normale [/font][font="DejaVu Serif, serif"]User mit Rechten zu privilegieren, die nicht „root“ sind. [/font]

    [font="DejaVu Serif, serif"]Der letzte Satz zuvor ist auch einer der Gründe, warum ich es für unabdingbar halte, den User Pi umgehend zu löschen. Eben weil er Setup-bedingt von vornherein mit Rechten ausgestattet ist, die einem User keinesfalls zustehen. [/font][font="DejaVu Serif, serif"]Und wieso sollte überhaupt ein Autologin mit P[/font][font="DejaVu Serif, serif"]i[/font][font="DejaVu Serif, serif"] durchlaufen und im Serverbetrieb 'ne aktive Shell laufen? [/font][font="DejaVu Serif, serif"]Ein weiterer Grund [/font][font="DejaVu Serif, serif"]für das Löschen des Users Pi [/font][font="DejaVu Serif, serif"]ergibt sich aus der Ableitung, warum es sinnvoll ist, „root“ keine SSH-Anmeldung zu erlauben, eben weil „root“ ebenso wie „pi“ ein allgemein bekannter User ist, mit denen man einfach mal ein paar Password-Spielchen treiben könnte. [/font]

    [font="DejaVu Serif, serif"]Und -[/font][font="DejaVu Serif, serif"]zu guter Letzt- [/font][font="DejaVu Serif, serif"]selbstverständlich muss der Port in der SSHD von 22 auf irgendwas geändert werden. Einfach aus dem Grund, damit verhindert wird, dass er [/font][font="DejaVu Serif, serif"]irgendwann [/font][font="DejaVu Serif, serif"]irgendeinem beliebigen SSH-HowTo aus dem Web folgt und sich riesig darüber freut, wie einfach er auf seinen Server zugreifen kann, weil er mal eben schnell im Router den gleichen Port 22 weitergeleitet hat. [/font]

    [font="DejaVu Serif, serif"]Letztendlich ist mir das natürlich alles egal…. jeder soll machen, wie er mag. Aber ich orientiere mich dann doch lieber eher an der Sichtweise der [/font] Unternehmen, [font="DejaVu Serif, serif"]die ich für qualifiziert in solchen Fragen halte. [/font]. Mir ist klar, dass man den Inhalt in jeder Richtung deuten kann und herauslesen kann, was man herauszulesen wünscht. Ich setze aber konsequent nur die Restriktionen um...... weil es eben bei mir keine anderen zu berechtigenden User gibt. Und ich bin sicher, dass diese Sichtweise für andere private Netzwerkadministratoren ebenfalls NICHT schädlich ist.

    jm2c

    Einmal editiert, zuletzt von WinterUnit16246 (20. Dezember 2015 um 12:23)

  • Schön wie du Aussagen anderer ohne Quellenangaben zitierst oder gar als deine ausgibst? :-/

    Wenn du einen Motorschaden hast, lässt du dann auch erst das Öl ab bevor du einen neuen Motor einbaust? (rhetorische frage)


    Wieso muss man einen Benutzer löschen um dessen sudo Rechte "zu entfernen"?
    Was darf der Benutzer pi ohne die uneingeschränkten sudo Rechte noch?
    Wieso setzen Distributionen wie Ubuntu auch heute noch verstärkt auf sudo wenn es denn aber derart unsicher sein soll?
    Wer kann/darf eigentlich sudo nutzen?
    Wer sprach hier von "Server"? Es ist ein gewaltiger Unterschied ob jemand privates bei sich Zuhause einen Rechner "ans Netz hängt" oder bei einem Hoster einen Server mietet.

    Beantworte diese Fragen - dann wird hoffentlich ersichtlich wieso ich "Das ist unnötig." schrieb.


    Mein letzter Beitrag in diesem Thread...

  • PS: Ich werde einfach den Benutzer pi umbenennen und den neuen mit sudo rechten ausustatten. :danke_ATDE:

    oder man nimmt einfach "sudo su" und loggt sich dannach wieder aus, so das man keinen fixen "root" account habe auf dem man sich per ssh einloggen kann ;)

    Entweder so oder den User pi löschen und einen neuen user anlegen.
    Dann solltest Du noch Deinen ssh Server sichern, d.h. z.B. keinen root Zugang zulassen u.v.A.m. Siehe dazu z.B. das Tutorial vom Der_Imperator: SSH sicher am Imternet
    Aber je nachdem welche Ports und Services Du aus dem Internet zugreifbar machst sind weitere SicherungsAktionen notwendig. Ich empfehle immer ein VPN zu benutzen sofern Du nicht Deine Raspi von Jedermann zugreifbar machen willst.

  • Schön wie du Aussagen anderer ohne Quellenangaben zitierst oder gar als deine ausgibst?

    Häh? :s Gehts noch...?.... wo habe ich auch nur eine einzige Aussage zitiert, die angeblich jemand anderes gesagt hat und wo ich eine Quelle hätte angeben müssen? Das sind alles ausschließlich meine eigenen Aussagen.

    Wenn du einen Motorschaden hast, lässt du dann auch erst das Öl ab bevor du einen neuen Motor einbaust? (rhetorische frage)

    Rhetorischer Unsinn.... denn ich spreche mich nur dagegen aus, die Knöpfe für den Fensterheber direkt an der Batterie anzuschließen, nach außerhalb der Fahrertür zu verlegen und nen Zettel dranzukleben "Nicht von Fremden zu benutzen".

    Wieso muss man einen Benutzer löschen um dessen sudo Rechte "zu entfernen"?


    Muss man nicht. Es ist nur quatsch einen User im System zu haben, der nicht verwendet wird, wenn man sich mit eigenem Account anmeldet.... vor allem vor dem Hintergrund, dass ein Server auch ohne aktive Anmeldung läuft und wenn schlimmstenfalls wegen der immense Menge an neuem Wissen durch ein neues Linux vergessen wird, pi's Default-Password zu verändern. Der sicherere Weg ist pi einfach zu löschen.

    Was darf der Benutzer pi ohne die uneingeschränkten sudo Rechte noch?


    Nichts. Und wenn er nichts darf und nicht verwendet wird, kann er auch einfach entfernt werden. Ich weiss nicht, was der Maintainer alles neben dem Autologin noch vorgesehen hat. Und der einfachste Weg zu verhindern, dass im Namen des Users Pi irgendwelche Jobs laufen, ist der, ihn einfach zu löschen. Und wenn es keine Jobs gäbe, schadet das löschen auch nicht.

    Wieso setzen Distributionen wie Ubuntu auch heute noch verstärkt auf sudo wenn es denn aber derart unsicher sein soll?


    Weil sie i.ü.S. genau wie die im Gestern leben, die gegen systemd sind. "sudo" ist vor dem Hintergrund der nutzbaren Policies völlig überflüssig, zumal die Policies ein genaueres Customizing ermöglichen, falls wirklich jemand diese root-Vertreter-Funktion in seinem Heimsystem benötigt. Und die Policies sind Debian-Standard.... insofern natürlich auch in Ubuntu.

    Wer kann/darf eigentlich sudo nutzen?


    Jeder! Wer sollte sinnvollerweise "sudo" nutzen.... meiner Meinung nach niemand. Eben weils unnötig und überflüssig ist.

    Wer sprach hier von "Server"? Es ist ein gewaltiger Unterschied ob jemand privates bei sich Zuhause einen Rechner "ans Netz hängt" oder bei einem Hoster einen Server mietet.

    Ich bin gerade dabei einen Dateiserver am Raspberry Pi 2 zu machen.


    Aufmerksamer lesen..... mir reicht das jedenfalls als Hinweis aus, dass hier Daten in einem Netzwerk verfügbar gemacht werden sollen. Insofern gehören da m.E. alle Programme entfernt, die keinen Zweck erfüllen, einschließlich eines Desktop-Environments (wenn da keiner aktiv dran arbeiten muss) und natürlich auch sudo. Aber das kann ja jeder anders handhaben.

    Beantworte diese Fragen - dann wird hoffentlich ersichtlich wieso ich "Das ist unnötig." schrieb.


    Habe ich. Ersichtlich ist für mich nur weiterhin, dass "sudo" nicht wirklich nötig ist und meines Erachtens nur eingesetzt werden sollte, um einem einzelnen Anwender im Rahmen eines umfassenderen Rechtemanagementes ganz explizite Aufgaben zu erlauben. Und das auch nur da, wo es kein Desktop-Environment gibt. Sobald ein Desktop vorhanden ist, erreicht man das notwendige über die Policies. Wobei ich persönlich auch ohne Desktop mit den Policies ohne Verluste Berechtigungen erlauben kann... und zwar nach der Prämisse "Es ist generell alles verboten, was nicht eng umgrenzt über die Policies ausdrücklich erlaubt ist." Fairerweise muss ich allerdings gestehen, dass ich bis vor kurzen auch noch sudo für ausdrückliche Sonderaufgaben (ifup, ifdown, umount) verwendet habe. Mittlerweile habe ich aber die Überzeugung, einen besseren Weg gefunden zu haben.

    Einmal editiert, zuletzt von WinterUnit16246 (20. Dezember 2015 um 15:21)

  • Wir diskutieren hier nur im Bezug auf den ThemenErsteller oder nicht? Also demjenigen, der diesen Thread erstellte und sein Anliegen in Beitrag#1 niederschrieb. Demnach ist hier also kein allgemeiner Thread ala "wie sichere ich mein Linux ab" ?!?
    Wenn ja, dann verallgemeinern wir das hier also nicht sondern beziehen uns stets auf speziell dem Anliegen hier in diesem Thread.
    Wenn nein, dann ist das hier der falsche Thread um es zu verallgemeinert zu beschreiben - dazu nannte framp bereits einen zumindest ansatzweise passenderen Thread.


    Muss man nicht. Es ist nur quatsch einen User im System zu haben, der nicht verwendet wird, wenn man sich mit eigenem Account anmeldet.... vor allem vor dem Hintergrund, dass ein Server auch ohne aktive Anmeldung läuft und wenn schlimmstenfalls wegen der immense Menge an neuem Wissen durch ein neues Linux vergessen wird, pi's Default-Password zu verändern. Der sicherere Weg ist pi einfach zu löschen.

    Wo steht denn das der TE überhaupt nicht mehr einen normalen Benutzer verwenden will? :-/

    Unter der Annahme, das direkte benutzen des root Benutzers, schrieb der TE das er künftig nur noch root nutzen wolle. Das dieser Gedanke schlecht ist haben Wir mittlerweile festgestellt, oder? Also was spricht dagegen den bereits vorhandenen pi Benutzer zu verwenden?

    Desweiteren hattest Du, in deinem ersten Beitrag hier, folgendes geschrieben:

    Wenn du es sicher haben willst [...] Als nächstes unbedingt den User Pi löschen, weil der wegen des Images schon Rechte voreingestellt hat. Dann richtest du einen ganz normalen User ein, der über keinerlei Extra-Rechte verfügt.

    Daraufhin schrieb ich dass das unnötig ist. Es reicht über visudo die speziellen Rechte zu entfernen. Man muss deshalb nicht einen Benutzer löschen und einen anderen neu erstellen. Tut mir leider aber insbesondere wenn Du daher kommst und meinst "Anfänger wissen es nicht besser", sollte man IMHO zu sehen es jenen richtig zu erklären oder zumindest richtig begründen. Aber angesichts dessen was du schreibst ist das Quatsch.


    Nichts. Und wenn er nichts darf und nicht verwendet wird, kann er auch einfach entfernt werden. Ich weiss nicht, was der Maintainer alles neben dem Autologin noch vorgesehen hat. Und der einfachste Weg zu verhindern, dass im Namen des Users Pi irgendwelche Jobs laufen, ist der, ihn einfach zu löschen. Und wenn es keine Jobs gäbe, schadet das löschen auch nicht.

    Genau. Nichts. Er wäre dann ein ganz normaler 08/15 Benutzer. Also bestehen die einzigen "Sonderrechte" darin das er sudo ohne Password Abfrage für uneingeschränkt alle Befehle nutzen darf. Folglich reicht es ihm die sudo Rechte zu nehmen.

    Wer außer Dir schrieb hier irgend etwas bezüglich Autologin ? :s

    Darf kein normaler 08/15 Benutzer irgendwelche (cron)jobs laufen haben? :-/


    Jeder!

    Das ist Falsch.
    Es darf jeder den Befehl "sudo" ausführen, ja. Aber es kann nicht jeder nutzen!
    Der auszuführende Benutzer muss explizit fürs NUTZEN des sudo Befehls eingestellt worden sein. Er darf also nur die Befehle über sudo ausführen die ihm explizit erlaubt wurden - und ebenso die Abfrage nach dem root Password kann entsprechend konfiguriert werden.
    Hat aber ein Benutzer keine expliziten sudo Rechte kann er auch nicht einfach via sudo zum Beispiel den Rechner rebooten!


    Aufmerksamer lesen..... mir reicht das jedenfalls als Hinweis aus, dass hier Daten in einem Netzwerk verfügbar gemacht werden sollen. Insofern gehören da m.E. alle Programme entfernt, die keinen Zweck erfüllen, einschließlich eines Desktop-Environments (wenn da keiner aktiv dran arbeiten muss) und natürlich auch sudo.

    Das gebe ich gerne zurück: Aufmerksamer lesen

    Was kann man unter einem Dateiserver verstehen?
    Das ist IMHO nicht gleich zu setzen oder automatisch identisch mit "Internet Server" oder "Server eines Unternehmens".
    Als "Dateiserver" kann bereits ein Rechner mit Samba im Heimischen Netzwerk bezeichnet werden. Oder eine Fritzbox mit NFS Freigabe.

    Ein Dateiserver muss auch nicht zwangsläufig etwas mit einem Shellbenutzer zu tun haben - hier wird also irgend etwas vermischt oder falsch interpretiert.

    Ich erinnere aber an dieser Stelle auch noch mal "Anfänger" und so... Nicht jedes von Anfängern verwendete Wort trifft tatsächlich zu. Man sollte also nicht jedes Wort auf die Goldwaage legen und sich daran dann festbeisen.


    Habe ich. Ersichtlich ist für mich nur weiterhin, dass "sudo" nicht wirklich nötig ist und meines Erachtens nur eingesetzt werden sollte, um einem einzelnen Anwender im Rahmen eines umfassenderen Rechtemanagementes ganz explizite Aufgaben zu erlauben. Und das auch nur da, wo es kein Desktop-Environment gibt. Sobald ein Desktop vorhanden ist, erreicht man das notwendige über die Policies. Wobei ich persönlich auch ohne Desktop mit den Policies ohne Verluste Berechtigungen erlauben kann... und zwar nach der Prämisse "Es ist generell alles verboten, was nicht eng umgrenzt über die Policies ausdrücklich erlaubt ist."

    ...Ich erwarte dann eine ausführliche Anleitung Deinerseits zum (imho komplexen) Thema "Policies" welche aber auch Anfängerfreundlich ist... Nur frag ich mich ob das nicht den Bogen ein klein wenig überspannt. Nunja, jeder wie er mag, gell?


  • @ThomasL: Das klingt nicht uninteressant mit den Policies. Hast Du nicht Lust mal ein Tutorial hier im Forum zu erstellen, wo Du beschreibst wie man Policies auf einer Raspberry konfiguriert und benutzt?

    Damit stellst Du mich vor ein schwieriges Problem….. nicht eins aus technischer Sicht, sondern eines aus konzeptioneller Sicht. Ich glaube, dass man sich vorher einige grundsätzliche Fragen beantworten muss, um eine Vorstellung davon zu bekommen, wo man sich hinsichtlich dieses Berechtigungs-Konzeptes überhaupt hinbewegen will.

    Zunächst mal muss man erkennen, wenn man die Benutzerrechte einrichten will, um welche Person es sich hierbei überhaupt handelt. Ist der User ein Windows-Umsteiger? Ist er von dort den permanenten Admin-Account mit abgeschalteter UAC gewohnt? Hat er sich bisher auf die Firewall und AV-Tools verlassen und eine entsprechende Erwartungshaltung etabliert? Diesem User sollte m.E. keinesfalls die Verwendung von „sudo“ nahegelegt werden, ebenso wenig wie Einträge zur pauschalen Berechtigung in der sudoers. Außerdem sollte man ihm nicht raten -gemäß dieser U-Nation-Unsitte- irgendwelche web-ppa's in seine sources.list einzutragen. Das hat jetzt weniger mit dem RPi zu tun, sondern allgemein mehr mit Linux. Der Pi hat vor diesem Hintergrund m.E. nur die zusätzliche Schwäche mit dem voreingestellten User „pi“ und dem default-Password, bei dem die Gefahr besteht, dass aus Unkenntnis schlicht und einfach vergessen wird, das zu ändern.

    Als nächstes ist die Frage zu beantworten, wie sinnvoll es überhaupt ist, einem Beginner-User „sudo“ zu erlauben, wenn dieser User sowieso das root-PWD kennt? Denn… wenn er das root-PWD kennt, soll er sich eben mit „su“ anmelden, das PWD eingeben und seinen Job in einwandfreier Account-Umgebung verrichten. Dann benötigt er dieses „sudo“ gar nicht und tappt nicht in Fallen, die ihm vielleicht gar nicht bewusst sind. Debian selber weist dich beim Setup suggestiv sehr deutlich darauf hin, ein root-Passwort zu vergeben. Erst im Nachsatz, nach Hinweis auf ein hohes Sicherheitsrisiko, wird im Installer erwähnt, dass ansonsten „sudo“ installiert wird.

    Dann gibt’s natürlich noch die erfahrenen Linux-User, die genau wissen, was sie tun und wie sie trotz sudo Risiken minimieren oder gar ausschalten können. Aber auch die müssen sich die Frage gefallen lassen, warum sie sich nicht eben als „root“ anmelden, wenn sie doch das root-Pwd kennen und sowieso „Herr des Systems“ sind. Fakt ist: gespart wird durch „sudo“ für die Systemadministration effektiv gar nix.

    Um jetzt den Bogen zu den Policies zu ziehen. Wenn ein erfahrener Benutzer gewohnt ist, mit „sudo“ zu arbeiten, erreicht er überhaupt nichts, wenn er die sudo-Funktionalität nun über die Policies „umleitet“. Außer Spesen nix gewesen…. also außer mehr Arbeit beim Einrichten kein sinnvoller Effekt. Für diese Fälle würde ich fast resümieren: Mach weiter sudo!

    Und wann doch die Policies? Ganz einfach, wenn ich einem unerfahrenen User, der an diesem System kein root-Passwd kennt, gewisse Dinge trotzdem erlauben will. Bei mir ist das beispielsweise die Funktion vor dem WLAN-ifdown die Mounts zu entfernen. Das bedeutet, die User an mehreren Laptops/Notbooks haben üblicherweise das Problem, dass das System mit 120-Sek-Stop-Jobs beim Shutdown hängt, weil WLAN beim Shutdown geschlossen wird, bevor die Mounts entfernt wurden.
    Oder auch, dass Mounts bei mobilen WLAN-Geräten generell flexibel erfolgen müssen, je nachdem ob der „eigene“ Server überhaupt verfügbar ist… denn das ist er bei offenen WISP eben nicht immer… mal ja, mal nein… je nachdem ob OpenVPN gestartet ist. Weil ich heute nicht mehr die fertigen Desktop-Environments verwende, sondern via OpenBox den Desktop plus Environment individuell ausgestalte, gibt’s natürlich auch das übliche Shutdown-, Suspend- und Restart-Problem, für das die User zunächst mal nicht berechtigt sind. Und genau all diese Aufgaben erlaube ich den Usern explizit über die Policies, ohne dass sie das merken, oder davon wissen, oder anderes zusätzlich dürfen.

    Ich weiss, dass das natürlich auch genauso über die sudoers gehen würde, nur will ich nicht dort „sudo“ nachinstallieren müssen, wo es nicht von vornherein vorgesehen ist, wie z.B. bei allen Debian-Distris. Ganz nebenbei bemerkt, alle aktuellen grafischen Debian-DE's berücksichtigen die Policies und regeln ihre Zugriffe darüber. Gegebenenfalls wird dabei sogar die Gruppe „sudo“ benutzt, die eben auch verwendet werden kann, wenn das Paket „sudo“ nicht installiert ist. Das ist auch völlig unkritisch, weil die Policies entsprechend restriktiv (!) gestrickt sind. Das heißt, der normal-User ist zwar in der Gruppe „sudo“ enthalten, aber er kann trotzdem nix darüber hinaus machen, was ihm nicht in den Policies explizit erlaubt ist. Wenn aber nun jemand auf die Idee käme, das Paket „sudo“ nachzuinstallieren, dann fängt er sich per default das hier in der sudoers ein:

    Code
    %sudo ALL=(ALL:ALL) ALL


    Und damit ist die gesamte bisherige beschränkende Policy-Sicherheit vom Desktop-Environment mit einem einzigen Schlag ausgehebelt. Ich muss als User für jegliches als root-auszuführende Kommando in der Konsole auf einmal nur noch mein eigenes Password eingeben. Na, da frag ich mich… ob man das wohl wirklich will.

    Mein Fazit… zusammengefasst in 3 kurzen Absätzen:
    - Auf einem desktoplosen Server braucht es kein „sudo“, wenn es nur einen Benutzer/Admin gibt, der auch noch das root-PWD kennt. Ebensowenig muss man sich dort mit den Policies befassen, weil es keine Sonderrechte für unprivilegierte User gibt…. und „root“ darf eh alles.

    -Auf ner Desktop-Maschine, die evtl. im Desktop-Environment die Policies verwendet, braucht man kein „sudo“, wenn der Benutzer entweder das root-PWD kennt oder weil er der einzige Benutzer ist. Für das Standard-Geschäft sind üblicherweise alle Erlaubnisse in den Policies per default eingerichtet. Sonderrechte sind besser in den Policies einrichten, damit sich die Berechtigungsprüfungen nicht gegenseitig aushebeln.

    - Sofern „sudo“ nicht vorinstalliert ist, und ein Anwender nicht das root-PWD kennt, muss man sich die Auswirkungen beim Nachinstallieren des Paketes „sudo“ genau anschauen, weil ggf. die Policies auch die alte Gruppe sudo verwenden könnten. Das heisst, allein durch die Nachinstallation von „sudo“ könnte die Sicherheit vollständig ausgehebelt werden. Das muss nicht mal bedeuten, dass der Anwender das bemerkt. Aber es kann bedeuten, dass es Konsequenzen hat, wenn er passend dazu andere Fehler begeht: z.B. dubiose ppa's oder Repositories in der sources.list, fehlende SSH-Sicherheit, was weiss ich, was noch… ich bin da leider kein Fachmann.

    Ich kenne auch leider nicht mehr alle Systeme…. Ubuntu und Linux Mint DE habe ich als ungeeignet verworfen. Es kann ja auch mittlerweile alles schon wieder anders sein…. aber dennoch denke ich, „sudo“ ist die Vergangenheit und das es schon heute eigentlich überflüssig ist.

  • Ich fiinde es lustig, wie hier imme run überall gesagt wird, dass man nicht als "root" arbeiten solle, dann aber alle Programme, die so mit Python geschrieben wurde (ooder auch anderen Programmiersprachen), als user "pi" mit dem Befehl "sudo" gestartet werden.

    Was glaubt ihr, wird mit diesen Programmen passieren?
    genau, sie werden als Root gestartet.
    Mit vollen Root-Rechten

    Das ist genauso sicher, als wenn man sich als Root anmeldet ud das Programm startet.

    Wenn, dann sollte man die Programme so starten, dass sie ohne "sudo" auskommen.

    Computer ..... grrrrrr

  • Ich fiinde es lustig, wie hier imme run überall gesagt wird, dass man nicht als "root" arbeiten solle, dann aber alle Programme, die so mit Python geschrieben wurde (ooder auch anderen Programmiersprachen), als user "pi" mit dem Befehl "sudo" gestartet werden.

    Das ist völlig aus dem Kontext gerissen. Siehe :

    Wenn, dann sollte man die Programme so starten, dass sie ohne "sudo" auskommen.

    Na dann schreib mal ein RPi.GPIO Script das ohne root-Rechte aus kommt.... Viel Erfolg!

    Also bitte - beachtet den Kontext und fangt nicht an nur weil jemand "A" schreibt von "B" zu sprechen, nur weil beides Teil des Alphabets ist.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!