Raspi Runterfahren - Passwort Blödsinn

  • Ich denke, man kann das unter bestimmten Bedingungen durchaus machen

    Können ja, sollen nein.

    Das Problem bei solch kranken Setups ist immer, dass sich irgendwann die äußeren Bedingungen ändern und dem nicht genügend Rechnung getragen wird. Und schwupps, hat man so eine Kiste unbeabsichtigt im Netz.

    Berechtigungen werden immer so restriktiv wie möglich vergeben.

    :2cents:

    Wenn du nichts zu sagen hast, sag einfach nichts.

  • lutz

    Grundsätzlich Zustimmung. Aber ich stufe solche Geräte dann auf den Status proprietärer Geräte ab, wie web-cams oder smart-tv ... also Geräte, deren Rechte man gar nicht einstellen kann. Und denen wird allen kurzerhand rigoros und komplett verboten, das Haus zu verlassen. Für die Nachhaltigkeit bei Veränderungen der Rahmenbedingungen (neuer Router) ist man selber verantwortlich. Bei mir sorgt eine eindeutige Dokumentation dafür.

  • Naja, wenn www-data nun unbedingt für einzelne Anwendungen sudo benötigt, dann würde ich auch nur diese Befehle zulassen mit einem sudo-Webscript, aber niemals pauschal dem www-data sudo-Rechte erteilen.

    Eigentlich ist das völlig egal, wenn sich der Default-User pi in der gruppe sudo befindet und dieser User dann sudo-kommandos mit Password oder wegen sudoers->nopasswd ohne Password absenden kann. Ist der passwd-keep nicht deaktiviert, was den nutzen von sudo auf einem System mit Desktop-Environment und typischen Anwendungsprogrammen quasi beseitigt, ist das System faktisch ein offenes System. Also... das bezieht sich auf Desktop-Systeme mit interaktiver Bedienung. Wirklich jede App, jedes Plug-in, jedes Addon kann sich unbemerkt wg. sudo root-rechte verschaffen.

    Wenn du Datenschutz herstellen willst, solltest du sudo tunlichst deinstallieren.

  • Zitat

    Wirklich jede App, jedes Plug-in, jedes Addon kann sich unbemerkt wg. sudo root-rechte verschaffen.

    Das Problem hast du erstmal unabhängig von sudo, wenn eine maliziöse Software dich dazu bringt, sie mit root-Rechten auszuführen.

    Wenn du nichts zu sagen hast, sag einfach nichts.

  • Das Problem hast du erstmal unabhängig von sudo, wenn eine maliziöse Software dich dazu bringt, sie mit root-Rechten auszuführen.

    Nein, das ist was völlig anderes. Du brauchst keine maliziöse Software mit root-rechten zu starten. Es reicht ganz einfach aus, "sudo nano smb.conf" zu starten, oder ein beliebiges anderes Linux-Tool, was man so zur Wartung benötigt.

    Bei der ganz normalen Verwendung von sudo braucht schadsoftware keine vorherige Unterstützung, die richtet sich einfach selber einen root Account ein.

  • sudo nano <foo>

    Wo siehst du dabei das Schadenspotential, wenn nano (oder $Programm deiner Wahl) sich bestimmungsgemäß verhält - also ausdrücklich keine Malware ist?
    Selbst wenn ein Timeout gesetzt ist, würde nano (ohne sudo aufgerufen) anschliessend keine root-Rechte haben. Und wenn es sich selbst mittels "sudo nano .." aufrufen würde, wäre es Malware.

    Wenn du nichts zu sagen hast, sag einfach nichts.

    • Offizieller Beitrag

    Kann das sein, dass wir diese Diskussion hier schon einmal geführt haben? ;) Bei mir gibt es sudo nur auf einen RPi und das ist mein Testpi.

    BTW: Wir driften ab. Ich wollte den TO nur warnen, dass er sich mit seinem Eintrag aus Beitrag #31 evtl. die Borg an Bord holen könnte.

  • sudo nano <foo>

    Wo siehst du dabei das Schadenspotential, wenn nano (oder $Programm deiner Wahl) sich bestimmungsgemäß verhält - also ausdrücklich keine Malware ist?
    Selbst wenn ein Timeout gesetzt ist, würde nano (ohne sudo aufgerufen) anschliessend keine root-Rechte haben. Und wenn es sich selbst mittels "sudo nano .." aufrufen würde, wäre es Malware.

    Das ist genau die übliche Sichtweise, die bedauerlicherweise die tatsächlichen Möglichkeiten ignoriert oder keine Kenntnis davon hat. Hierbei wird immer von chronologischer Kongruenz oder unmittelbaren kausalen Zusammenhängen bei der Kompromittierung ausgegangen, das heisst, die tatsächliche Kompromittierung findet genau in dem Moment statt, wenn der User einen sudo-Befehl absendet oder als root tätig ist. Das ist aber leider totaler Quatsch.

    Wirklich jedes völlig normale Anwendungsprogramm, völlig egal ob es der LO-Writer ist, oder Chromium, oder Firefox, oder Gimp, oder ein beliebiges Browser-Addon, oder ein beliebiges Plugin eines Programms (wie beim DoubleCmd oder DeadBeef) üblich, oder ein beliebiges Java-Script kann die Attacke zeitlich total losgelöst von den User-Aktivitäten vorbereiten. Was ist allen gemeinsam? Sie laufen im User-Space des Anwenders... und haben damit Lese und Schreibrechte auf die .bashrc oder auch auf .bash_aliases.

    Ein einfachster primitiver Einzeiler, von irgendeiner dieser Apps unbemerkt in die .bashrc geschrieben und der sich beim Start des Terminals wegforkt, prüft damit in jedem (!) geöffneten Terminal im Minuten- oder 5-Minuten-Rhythmus auf aktiven Password-Keep, ohne überhaupt zu wissen, was der User da gemacht hat. Ist der Pwd-Keep aktiv, erstellt der Fork einen neuen User mit eigenem Passwd, added den zur Gruppe "sudo" und das wars..... erledigt, System gekapert. Ab dann hat die App nach belieben root-Rechte und kann die .bashrc wieder wie zuvor herstellen. Hat der Fork einen cleveren User-Namen gewählt, wird den wirklich jeder für einen systemnamen halten und nix auffälliges daran finden. Das ist ein Einfallstor, was quasi nicht oder wirklich nur rein zufällig zu entdecken ist.. Ich habe das vor einigen Monaten mal herausgearbeitet.... das ist wirklich nur ein dämlicher Einzeiler in der .bashrc und funktioniert absolut zuverlässig, und zwar in jedem (!) Terminal, sobald der User ein sudo-Kommando absetzt. Tja, und zur Manipulation der ~/.bahsrc brauchts keine root-rechte.

    Die sudo-verwendenden Distris, die auch noch fremd-PPAs unterstützen, haben quasi aus nem sicheren Linux nen löcherigen Käse gemacht. Sudo ist in der derzeitigen Ausprägung und bei Verwendung auf normalen Desktop-PCs für mich einer der derzeit größten Exploits.

    Man kann das abschalten, wenn man den Timout auf 0 sendet... aber damit ist die Verwendung von Sudo nur noch eine Farce.... die man genau so gut mit einem .bashrc-alias auf "pkexec" wrappen kann... womit man sich wieder das ganze sudo sparen kann. "sudo" ist auf einem Desktop-System einfach nur völlig unnötiger Schrott, der zudem auch noch echte Risiken beinhaltet.

    Einmal editiert, zuletzt von WinterUnit16246 (15. Februar 2018 um 12:26)

  • Was ist allen gemeinsam? Sie laufen im User-Space des Anwenders... und haben damit Lese und Schreibrechte auf die .bashrc oder auch auf .bash_aliases.

    BTW: Schreiben können sie nicht, wenn das immutable Flag gesetzt ist:

    Code
    :~ $ lsattr .bashrc
    ----i---------e---- .bashrc

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Korrigiere mich, aber der Remotedesktop doch auch nur ein Programm, das lediglich vorinstalliert ist und zum Lieferumfang von Win gehört. Fest eingebaut, naja. Aber das ist eigentlich egal.

    Mit fest eingebaut meinte ich das. Ich muss nicht erst ein Programm herunterladen, installieren und konfigurieren.

    Bekommst Du denn Zugriff auf Display:0 (steuerst die lokale session des Pi also fern)? Ich glaube nicht.

    Keine Ahnung was Display:0 sein soll. Ich sehe den Desktop des PI in Echtzeit und steuere ihn fern, ja. Es ist gleichzusetzen mit Tastatur und Display am Pi selber.

    Und eine lahme Verbindung ist es auch nicht. Ich klicke aufs Menü und es öffnet sich sofort. Ich würde behaupten, man erkennt keine zeitliche Verschiebung zwischen Aktion und Reaktion.

    Verschlüsselt ist die Verbindung auch nicht.

    Ist für mich irelevant. Laut einem Check von heise kommt keiner durch meinen Router durch. Und der Pi enthält nichts Sicherheitsrelevantes.

    Ich hatte gestern geschrieben, das alte Image noch mal zu testen. Habe ich heute, soeben gemacht. Und dort kann ich die Session des PI beenden und den PI per RDP ohne Passworteingabe herunter fahren. Es liegt also definitiv am neuen Stretch mit Desktop.

    Das nur der Vollständigkeit halber.

    MfG

  • Keine Ahnung was Display:0 sein soll. Ich sehe den Desktop des PI in Echtzeit und steuere ihn fern, ja. Es ist gleichzusetzen mit Tastatur und Display am Pi selber.

    Du siehst also am lokal angeschlossenen Monitor gleichzeitig Mausgeschubse und Fenstergeöffne so wie auf Deinem fernsteuerndem Rechner? Wie hast Du das eingerichtet?

    per RDP ohne Passworteingabe herunter fahren. Es liegt also definitiv am neuen Stretch mit Desktop.

    Das stimmt definitiv nicht. Ein Jessie (aufbauend von der letzten offiziellen Jessie Version) mit allen aktuellen Updates zeigt gleiches Verhalten. Immerhin auf Anhieb und nicht erst nach Logout/Login.

    Gruß, STF

  • BTW: Schreiben können sie nicht, wenn das immutable Flag gesetzt ist:

    Mach mal 'ne Schätzung, auf wieviel Systemen das a. per default bereits nach dem Installer gesetzt ist und b. wieviele User das kontrollieren bzw. es manuell setzen. Im Moment hat die Aussage für mich den gleichen Informationswert, wie die Aussage "BTW: Schreiben können sie nicht, wenn der Rechner ausgeschaltet bleibt:" hätte.

    :conf:

  • Du siehst also am lokal angeschlossenen Monitor gleichzeitig Mausgeschubse und Fenstergeöffne so wie auf Deinem fernsteuerndem Rechner?

    Ich habe keinen lokal angeschlossenen Monitor. Deshalb arbeite ich mit RDP. Ich würde deine Annahme verneinen, ist ja kein Teamviewer.

    Das stimmt definitiv nicht.

    Doch, muss ich leider erneut behaupten. Anders kann ich mir das unterschiedliche Verhalten nicht erklären. Beim Jessie mit Desktop brauch ich mich nicht mit Passwort abmelden. Und ja, der Pi fährt definitiv runter, ohne Passwortabfrage.

    Beim Stretch mit Desktop muss ich ein Passwort eingeben.

  • Moin Guido64,

    es wäre schön zu wissen, was denn bei dir in der Datei 010_pi-nopasswd gestanden hat.

    Gruss Bernd

    hi Bernd. das hatte ich gestern in #15 glaube ich geschrieben. Es sieht genau so aus wie bei dir!

    Wenn ich heute so sehe, was hier an Wissen aufeinander prallt, bekomme ich Angst!:stumm: Ich versteh auch nur die Hälfte:no_sad:


    Ich wollte doch nur wissen, wie ich die Passwort-abfrage so weg bekomme, dass ich meine PHP- Seite wieder zum Neustart oder runter fahren nutzen kann.


    Vielleicht hat da jemand eine Idee bzw. Erfahrung, wie ich das so umsetzen kann, was ich in #31 bezüglich der Datei 010_pi-nowasswd geschrieben habe,

    www-data ALL=(ALL) NOPASSWD: ALL < - - - das ist wohl definitiv falsch so !!!

    www-data ALL=(ALL) NOPASSWD: /usr/bin/wichtig/neustart.php

    dass ich nur die Freigabe für eine spezielle PHP Datei oder ein Verzeichnis bekomme, so dass www-data nicht volle Rechte bekommt.

    Es sind für mich (im Moment) nur 2 Dateien, die das Recht brauchen.

    Großen Dank für die Mühe die sich alle machen!:thumbup:

    Ich habe eine Raspi Beere 3 und freue mich, dass sie läuft. Ich programmiere gern und freue mich wenn es auch funktioniert. Aber grundsätzlich hab ich keine Ahnung davon :conf:

    Bitte löscht nie dieses Forum! Hier steht alles drin was ich mir merken muss!

  • Ich wollte doch nur wissen, wie ich die Passwort-abfrage so weg bekomme, dass ich meine PHP- Seite wieder zum Neustart oder runter fahren nutzen kann.

    Da frage ich Dich gerne doch noch einmal, warum diese Lösung in meinem Post

    Raspi Runterfahren - Passwort Blödsinn

    für Dich schlecht oder nicht ausreichend ist...?... und das sogar vor dem Hintergrund, was ich Dir auch gesagt habe, nämlich das Shutdown als eigenständiges Programm mittlerweile gar nicht mehr existiert, sondern nur ein Wrapper auf systemctl ist....was ich Dir auch vorgeschlagen habe. So richtig verstehe ich Dich nicht mehr und jetzt weiss ich auch nicht, wie man Dir helfen soll ein Problem zu lösen, was nur dadurch entsteht, weil Du den richtigen Weg als Lösung nicht akzeptierst.

    Ich bin damit raus....

  • Da frage ich Dich gerne doch noch einmal, warum diese Lösung in meinem Post

    Raspi Runterfahren - Passwort Blödsinn

    für Dich schlecht oder nicht ausreichend ist...?... und das sogar vor dem Hintergrund, was ich Dir auch gesagt habe, nämlich das Shutdown als eigenständiges Programm mittlerweile gar nicht mehr existiert, sondern nur ein Wrapper auf systemctl ist....was ich Dir auch vorgeschlagen habe. So richtig verstehe ich Dich nicht mehr und jetzt weiss ich auch nicht, wie man Dir helfen soll ein Problem zu lösen, was nur dadurch entsteht, weil Du den richtigen Weg als Lösung nicht akzeptierst.

    Ich bin damit raus....

    wenn ich zu Hause bin bin schaue ich das durch was du letzte Nacht geschrieben hast. Nur vom Lesen kann ich nicht beurteilen, ob das geht oder den Erfolg bringt.

    PS: ich habe nix von schlechter oder nicht ausreichender Lösung geschrieben!

    Ich habe eine Raspi Beere 3 und freue mich, dass sie läuft. Ich programmiere gern und freue mich wenn es auch funktioniert. Aber grundsätzlich hab ich keine Ahnung davon :conf:

    Bitte löscht nie dieses Forum! Hier steht alles drin was ich mir merken muss!

  • .... wieviele User das kontrollieren bzw. es manuell setzen. Im Moment hat die Aussage für mich den gleichen Informationswert, wie die Aussage "BTW: Schreiben können sie nicht, wenn der Rechner ausgeschaltet bleibt:" hätte.

    Das werden evtl. genau so viele oder so wenige User sein, wie die, die z. Zt. mit Ubuntu oder mit Raspbian auf sudo verzichten bzw. sudo nicht benutzen.

    Naja, zu sagen ""BTW: Schreiben können sie nicht, wenn der Rechner ausgeschaltet bleibt:", würde m. E. ja suggerieren, dass es für diese Dateien bei eingeschaltetem Rechner und mit sudo, überhaupt keinen Schutz gibt, was aber so nicht stimmt.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • m. E. ja suggerieren, dass es für diese Dateien bei eingeschaltetem Rechner und mit sudo, überhaupt keinen Schutz gibt, was aber so nicht stimmt.

    Das ist korrekt. Der Schutz komt aber nicht vom Linux-System, sondern ist imho in der nebensächlichen Tatsache begründet, dass der Rechner glücklicherweise ja noch hinter einem Router mit NAT läuft und das der Router bei IPv6 zumindest noch SYN-Pakete von draußen blockt. Und es liegt daran, dass es derzeit noch keinen wirklichen Druck auf Linux-Systeme gibt.... Linux ist als Opfer einfach zu uninteressant.

    Ich sehe das zur Zeit eher so, wie ich ein Haus weitab von allen anderen sehe, wenns weit abseits in der Wildnis liegt. Die Anwohner kommen bestens auch ohne abzuschließen klar, weil keiner da ist, der rein will. ... nur wenn mal jemand kommt, geht er einfach rein.

    Das werden evtl. genau so viele oder so wenige User sein, wie die, die z. Zt. mit Ubuntu oder mit Raspbian auf sudo verzichten bzw. sudo nicht benutzen.

    Ich denke, es wird den meisten schlichtweg egal sein, weil die digitale Gefährdung für sie nur ein imaginäres Gebilde ist, den meisten völlig unbegreiflich, ohne jegliche Vorstellung, was da überhaupt passiert, begleitet vom Gedanken "ich habe eh nix zu verbergen, kann jeder sehen". Und natürlich auch vor dem Hintergrund der Tatsache, dass sie das ausspioniert-werden körperlich oder emotional gar nicht wahrnehmen. Der digitale Einbruch wird ganz anders wahrgenommen, als würden fremde zuhause in der Unterwäsche rumwühlen.Beim digitalen Einbruch gibts keine fühlbaren Konsequenzen, wenn mans herausfindet, ärgern sich die meisten allenfalls aus Prinzip, aber nicht weil sie das Geschehene wirklich verstehen. Das ist das Dilemma mit der privaten EDV , die Abhängigkeit ist schon zu groß, als das man heute noch drauf verzichten kann... und Aufwand fürs Lernen will auch keiner... es muss möglichst ohne Fragen zu stellen einfach nur funktionieren....

    Ich hatte heute einen kurzen Smalltalk in der Bank... da erzählte mir die Mitarbeiterin, dass man sich in Bankkreisen bereits über diese von mir an anderer Stelle schon erwähnte Liberalisierung des Datenhandels unterhalten hat. Die haben das Problem, dass es sein kann, dass Amazon in seinen Geschäftsbedingungen hinterlegt, eine Abfrage auf das Lastschriftkonto des Kunden durchführen zu dürfen. Wenn der Kunde das nicht explizit ablehnt, was die meisten nicht tun, sondern nur den Haken bei AGB gelesen setzen, dann hat der Kunde damit seine Einwilligung gegeben, dass Amazon alle Umsätze des Kunden bei seiner Bank abfragen darf. Was denkst Du, wieviel Leute ohne es zu wissen, irgendwann Amazon erlauben, alle Kontobewegungen abzurufen?

    Als ich das gehört habe, hat sich gleich ein Kotzreiz breit gemacht. Man muss das, was hier passiert, alle diese Löcher und möglichen Verstöße gegenm den von uns geforderten Datenschutz an allen Stellen ansprechen, immer wieder, immer neu und die Leute sensibilisieren, dass sie nicht in solche Fallen geraten.

    j.m.2.c.

  • @ThomasL

    Dein sudo-Gebashe in Ehren, aber wo glaubst du den Unterschied zu einer Schadsoftware zu sehen, die mittels pkexec als UID=0 läuft?

    Ohne weitere Schutzmassnahmen ist das Szenario identisch. Und um z.B. des Users ~/.bashrc zu beschreiben benötigt man nun wirklich kein sudo.

    pls stop FUD<EOD>

    Wenn du nichts zu sagen hast, sag einfach nichts.

  • Hallo ThomasL,

    ich hoffe, du bist nicht nachtragend, wenn ich erst jetzt dazu komme, das zu testen was du halt gestern schon veröffentlicht hast;).

    Ich habe mich heute das erste mal mit "root" auf der Beere bewegt. Danke, dass ich das lernen durfte! (ernst gemeint)

    Wenn ich das richt gemacht habe, bitte den Daumen hoch... Wenn nicht sofort schimpfen!

    Um als "root" Nutzer was machen zu können, habe ich als Nutzer "Pi" einfach eine Konsole geöffnet und eingeschrieben:

    Code
    pi@raspberrypi:~ $ sudo su          <---- "sudo su" , das Zauberwort eingeben und Enter duercken
    root@raspberrypi:/home/pi#          <---- nun wird alles "grau" aber die Rechte als "root" sind deine


    Und nun habe ich auch das eingegeben, was ich prüfen sollte:

    cat /usr/share/polkit-1/actions/org.freedesktop.login1.policy | egrep -v "message|description" | grep "power-off" -A 6

    Das Ergebnis sieht so aus, wie du sicher vorher gewusst hast:

    Du schreibst, "Wenn in den Policies das folgende drinsteht: auth_admin oder auth_admin_keep... dann ändere das einfach auf yes,"

    Das werde ich als nächstes versuchen.

    Ich werde sofort Vollzug melden, wenn ich das geschafft habe oder auch nicht!

    Aber prüfen ob der Befehl systemctl poweroff das System runter fährt kann ich nicht gleich, sorry. Ich brauche erst ne neue SD Karte, weil seit gestern knapp Null Uhr mein System immer freiwillig runter fährt, wenn ich das will, obwohl ich den Eintrag www-data ALL=(ALL) NOPASSWD: ALL aus der Datei <kbd>etc/sudoers.d/010_pi-nopasswd</kbd>entfernt habe.

    Guido

    NACHTRAG:

    wer sich mit :

    Code
    pi@raspberrypi:~ $ sudo su

    als "root" angemeldet hat, kann mit einem einfachen "exit" das auch wieder beenden, ohne dass sich die Konsole schließt. Denke, das sollte man dann auch wissen.

    Ich habe eine Raspi Beere 3 und freue mich, dass sie läuft. Ich programmiere gern und freue mich wenn es auch funktioniert. Aber grundsätzlich hab ich keine Ahnung davon :conf:

    Bitte löscht nie dieses Forum! Hier steht alles drin was ich mir merken muss!

    Einmal editiert, zuletzt von Guido64 (15. Februar 2018 um 18:50)

Jetzt mitmachen!

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