Datei Attribute - immutable oder strikte Root-User Trennung

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Folgendes aus dem Thema "Raspi Runterfahren - Passwort Blödsinn" herausgelöst. Nach: Raspi Runterfahren - Passwort Blödsinn

    Zitat

    rpi444 schrieb:

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

    Zitat von ThomasL:

    Zitat

    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.

    Es ging um ~/.bashrc und das immutable Attribut, aber betrifft vermutlich auch andere Situationen? Es gibt da einen ganzen Haufen Datei Attribute man chattr und man lsattr die mir bisher unbekannt sind. Mein Frage ist, ob mit i Attribut auf .bashrc das System wirklich sicherer ist? Hier sieht es so aus, was auch Standard zu sein scheint:

    Code
    pi@raspberrypi:~ $ lsattr .bashrc --------------e---- .bashrc

    Wenn immutable i gesetzt ist, dann ist kein schreiben/löschen mehr möglich als Benutzer pi und per sudo. Schön, das von ThomasL beschriebene mögliche Sicherheitsproblem ist damit "beseitigt". Zumindestens solange sudo nicht existiert. Man/jemand kann ja, wenn sudo vorhanden ist, mit diesem, immutable wieder entziehen und somit wieder schreiben/löschen. Müsste ich also /usr/bin/sudo löschen, damit immutable setzen Sinn macht? Wenn ja, wie komme ich dann ohne sudo aus?

    Einmal editiert, zuletzt von daxb (15. Februar 2018 um 18:39)

  • Datei Attribute - immutable oder strikte Root-User Trennung? Schau mal ob du hier fündig wirst!

  • Müsste ich also /usr/bin/sudo löschen, damit immutable setzen Sinn macht?

    Nein, wenn Du nicht willst, musst Du sudo nicht löschen, denn ThomasL hat ja in diesem Zusammenhang auch noch Folgendes geschrieben:

    Zitat

    Sie laufen im User-Space des Anwenders... und haben damit Lese und Schreibrechte auf die .bashrc oder auch auf .bash_aliases.

    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

  • Wenn immutable i gesetzt ist, dann ist kein schreiben/löschen mehr möglich als Benutzer pi und per sudo. Schön, das von ThomasL beschriebene mögliche Sicherheitsproblem ist damit "beseitigt". Zumindestens solange sudo nicht existiert. Man/jemand kann ja, wenn sudo vorhanden ist, mit diesem, immutable wieder entziehen und somit wieder schreiben/löschen. Müsste ich also /usr/bin/sudo löschen, damit immutable setzen Sinn macht? Wenn ja, wie komme ich dann ohne

    Dir muss dabei nur klar sein, dass Du damit einen Workaround etablieren möchtest, der die Probleme beseitigen soll, die erst durch den Missbrauch dieses bestimmten Tools entstanden sind. Fakt ist, "sudo" wurde NIE für den Zweck geschaffen, wofür es derzeit verwendet wird. Und zu verdanken haben wir das Mark's und Clem's Distributionen, die es den Windows-Umsteigern einfacher machen wollten, in dem sie die Windows-Fehler wiederholen.

    Es gibt weder eine zwingende Notwendigkeit noch einen sinnvollen Grund, sudo innerhalb eines normalen Ein-User-Desktop-Environments durch diesen User zu nutzen, oder innhalb einer privaten Client-Server-Umgebung, mit nur einem Admin..... der als normaler User unter seiner UID eigentlich per se unberechtigt sein sollte. sudo und sudoers und undurchschaubares Zusammespiel mit dem Polkit ist schlichtweg eine Ansammlung von Kaputtheit, weils aus einer Zeit vor den grafischen Enduser-Desktops stammt. "sudo" kann keine grafischen Anwendungen, dafür braucht es weitere schlecht angetackerte Prothesen wie gksudo und kdesudo (ich glaube, so hießen die).

    • Ein Lösung wäre, den Timeout auf 0 zu setzen, dann muss man bei jedem sudo-Kommando das Pwd eingeben
    • Die bessere Lösung wäre, wenn ich sowieso jedesmal das PWD eingeben muss, einen sudo-Alias auf pkexec einzurichten und sudo zu purgen
    • Eine noch bessere Lösung wäre, sudo zu purgen und spezielle Polkit-Berechtigungen zu verwenden, die auch mit grafischen Anwendungen klarkommen
    • Die beste Lösung wäre, (wie llutz schon festgestellt hat, Berechtigungen weitesgehend einzuschränken) und darauf zu verzichten, dass ein normaler User mit der Aneignung von root-Rechten das System verändern kann. Das ist Windowsdenke, weil sich der User mit seinen Privilegien gut fühlt, weil er der Boss ist. In Wahrheit ist das einfach nur dämlich. Ich habe auf keinem einzigen unserer System Rechte, die über mein Homedir hinausgehen. Ich selber habe keinerlei Berechtigungen, beliebige Kommandos als User ThomasL mit root-Rechten abzusetzen. Warum nicht? Weil man das nicht braucht. Wenn ich was verändern will, melde ich mich als root an und tu was zu tun ist, danach melde ich mich als root ab. Ich habe für mich ein Passwd, root hat ein eingenes heftiges Password, bei Systemarbeiten muss ich das einmal eingeben. Und für jene Routine-Jobs, wo ich kein Pwd eingeben will, nutze ich das Polkit. Einfacher und sicherer gehts imho derzeit nicht.

    j.m.2.c.

    Einmal editiert, zuletzt von WinterUnit16246 (15. Februar 2018 um 19:11)

  • Dir muss dabei nur klar sein, dass Du damit einen Workaround etablieren möchtest, der die Probleme beseitigen soll, die erst durch den Missbrauch dieses bestimmten Tools entstanden sind.

    Du meinst mit Workaround jetzt das mit immutable setzen und sudo löschen, oder jegliche Änderung wie das von dir beschriebene strikte Trennen von User (nur /home) und Root mit ggf. Polkit?

    Generelle möchte ich erstmal so wenig wie möglich ändern, solange ich das System nicht gut genug kenne. Also nicht kaputt konfigurieren. Etwas gewundert habe ich mich schon, das ich als User mehr oder weniger direkten Zugriff (vor allem schreiben) auf / habe, oder diesen über sudo nach belieben erhalte. Seit ich den RPi habe, bin ich täglich in der Shell und (muss) mit sudo arbeiten. Im Internet, Foren, Anleitungen/Wikis/... ist alles voll mit sudo hier, sudo da. Dachte schon das wäre "normal" für die Linux Betriebssysteme. Mir fehlt da noch die Gesamtübersicht um das alles zu verstehen/einordnen zu können.

    Wie einfach/schwierig/kompliziert/pflegeleicht ist denn das Einrichten einer strikten Root-User Trennung + Polkit? Z.b. bei einem Upgrade auf eine neue Betriebssytem Version.

    • Offizieller Beitrag

    Im Grunde ist es ganz einfach. Ein "einfacher" User macht seinen Kram in seinem Bereich. Um das System kümmert sich der Admin, also der menschliche User, der das root-Passwort kennt. ;) Im Bezug auf den RPi ist das oft ein und die selbe Person, also Du. Wenn ein update gemacht werden soll, dann meldest Du Dich mit dem User root an und verwaltest, upgradest, installierst Software, what ever.

    Wenn das System einmal eingerichtet ist, gibt es keinen Grund für eine root-Hintertür, wie das mit sudo der Fall ist. Du kannst ganz normal damit arbeiten ohne root-Rechte. Der Grund für die vielen sudo in den ganzen Anleitungen ist, dass das Anleitungen zu Installationen sind und man dafür natürlich meistens root-Rechte braucht.

    Gut, der RPi unterscheidet sich natürlich erheblich von einem normalen Linuxkübel, alleine schon durch die GPIO. Evtl. gibt es auch Situationen, in denen ein normaler User ohne root-Rechte nicht weiter kommt, aber dafür gibt es andere Möglichkeiten, als sudo inflationär zu benutzen.

    :2cents:

  • Wie einfach/schwierig/kompliziert/pflegeleicht ist denn das Einrichten einer strikten Root-User Trennung + Polkit? Z.b. bei einem Upgrade auf eine neue Betriebssytem Version.

    Das ist überhaupt kein Aufwand... :lol:... und deswegen ist es eigentlich kaum zu verstehen, dass sich dieses bescheuerte sudo-gksudo-kdesudo-Trio so dermaßen hartnäckig hält. Du musst keine Angst haben, mit Änderungen jetzt das ganze System durcheinander zu bringen... das passiert nicht.

    Es sind nur wenige Schritte notwendig.

    1. Du richtest für root ein Password ein, mit sudo su und dann passwd. Das Pwd sollte sich unbedingt von Deinem User-PWD unterscheiden. Ich empfehle, aber, dass Dein Username und das PWD auf Client-PC und SSH-Server identisch ist... das vereinfacht es deutlich.... nur das root-PWD sollte ein anderes sein.

    2. Danach kannst Du vor Arbeiten am System einfach als normaler User su im Terminal eingeben, dann das abgefragte root-PWD und kannst dann alle Arbeiten als root ohne weitere Password-Abfrage erledigen. Am Ende meldest Du dich mit exit wieder als root ab und bist wieder der normale User.

    Bis hierhin hat sich also nicht wirklich viel geändert, bis auf die Tatsache, dass Du auf "sudo-Kommandos" verzichtest und einfach direkt root wirst. Du kannst alles genau so tun, wie zuvor. Also eigentlich ist es mehr Disziplin des Users, und viel weniger echte Änderung am System.

    Jetzt folgt ein weiterer Schritt, der keinesfalls vergessen werden darf:

    3. Du kontrollierst die sshd_conf, um eindeutig festzulegen, dass sich root nicht anmelden darf. Mit der folgenden Conf ist überhaupt keine Anmeldung mehr per SSH möglich:

    Code
    # egrep -i "authentication|rootlogin" /etc/ssh/sshd_config
    HostbasedAuthentication no
    PubkeyAuthentication no
    PermitRootLogin noPasswordAuthentication no
    ChallengeResponseAuthentication no
    KerberosAuthentication no
    GSSAPIAuthentication no

    Wenn Du Dich via einfachem Password mit Deinem "User" anmelden willst, setzt Du PasswordAuthentication yes

    Oder alternativ, wenn Du Dich via Keyfile und mit Deinem "User" anmelden willst, setzt Du PubkeyAuthentication yes

    Damit wird also gesetzt, dass Du künftig in einem Terminal mit Deinem Usernamen die SSH-Verbindung startest und Dich zum Server verbindest. Dort kommst Du ebenfalls mit Deinem Usernamen an und kannst dann mit su (wie oben) und dem root-Pwd zu root werden (sofern das benötigt wird) und die notwendigen Änderungen durchführen.

    Wenn Du Keyfiles nutzen möchtest, musst Du sie natürlich vorher erstellen und auf SSH-Server und SSH-Client kopieren. Aber ich würde nicht dauerhaft beide Auth's gleichzeitig erlauben.Ich empfehle, den PWD-Auth nur vorübergehend zu verwenden und unbedingt auf Pubkey-Auth umzustellen. Damit ist die Anmeldung nur von Systemen möglich, auf denen der entsprechende Pubkey installiert ist. Ein Zugang ohne Pubkey ist nicht mehr möglich. Das erhöht die Sicherheit gravierend.

    Aber es ist ein bisschen tricky, wenn Du diese Änderungen auf dem SSH-Server via SSH einstellst, denn bei einem Fehler könntest Du Dich selber aussperren. Also machst Du das ein einer Session, ohne diese Session nach den Änderungen zu beenden. Du kannst dann einfach ssh restarten und in einem neuen Terminal versuchen, ob dort eine zweite SSH-Anmeldung klappt. Wenn sie nicht klappt, kannst Du in der ersten noch offenen Sitzung wieder korrigieren, wenn die Anmeldung klappt, kannst Du auch die erste Sitzung schliessen.

    Das wars an echten Änderungen. Bis zu diesem Moment funktioniert auch immer noch "sudo". Und jetzt schaust Du Dir das einfach ein paar Tage an und tust das, was ich oben mit Disziplin bezeichnet habe... mit Disziplin auf die Verwendung von "sudo" verzichten und bei Arbeiten am System immer brav vorher mit su zu root werden.Falls es so sein sollte, dass Du nach einigen Tagen dieses "sudo" gar nicht mehr vermisst, entferne Deinen User einfach aus der Gruppe "sudo" mit i.ü.S. deluser thomas sudo.

    Und was Du unbedingt machen solltest, statt des Default-Users "pi" nur einen User mit Deinem Namen und einem eigenen PWD verwenden. Das heisst, Du richtest den User "daxb" ein, gibtst ihm ein PWD und meldest Dich nur noch mit diesem User an.... und kannst natürlich jederzeit mit su und dem root-PWD auch zu root werden, ganz ohne jetzt erst wieder Heckmeck mit fehlenden Rechten in der sudoers bzw. Gruppe sudo zu haben. Und wenn weitere Tage vergangen sind und Du den User "pi" gar nicht mehr gebraucht hast, würde ich zuerst "pi" aus dem System entfernen und dann vielleicht auch "sudo".

    Mit diesen einfachen Maßnahmen hast Du Dein System deutlich gehärtet... ohne tatsächliche Einschränkungen zu haben. Und bis zu diesem Moment hast Du mit dem Polkit noch gar nix zu tun gehabt.

    Erst wenn sich neue Anforderungen ergeben, zum Beispiel einen grafischen Filemanager als root zu starten, dann kann man das mit einer Policy erlauben... und das funktioniert dann ohne Prothesen perfekt. Aber ... auch davon würde ich abraten... installiere einfach den midnight-commander und verwende den bei Bedarf im root-Terminal. Mittlerweile bin ich der Meinung, dass das viel direkter und schneller geht, als diese furchtbar umständlichen grafischen Filemanager. Mit dem Polkit kann man sich perfekt zugeschnittene Berechtigungen erstellen, viel präziser, als das mit sudo möglich ist. Aber warte erst mal ab, ob und wann Du das wirklich brauchst.

    Und am wichtigsten ist die Erkenntnis, dass man root-Rechte niemals als normaler User braucht.... die sind wirklich nur bei Änderungen am System erforderlich. Keine Anwendung im normalen User-Bereich verlangt root-Rechte.

    Hth

    • Offizieller Beitrag

    Ergänzend möchte ich noch erwähnen, dass Du den neu erstellten user daxb auch zu den Gruppen hinzufügen musst, in denen der user pi ist. Natürlich nicht in die Gruppen sudo und pi. ;)

  • ..., dass Du den neu erstellten user daxb auch zu den Gruppen hinzufügen musst, in denen der user pi ist.

    Das ist nicht zwingend erforderlich, sondern davon abhängig wie er seinen PI mit dem neuen user nutzen will. Z. B. auf einem meiner PIs mit einem neu erstellten user:

    Code
    :~ $ id
    uid=1###(<neuer-user>) gid=100(users) groups=100(users),111(sshusers)

    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

    • Offizieller Beitrag

    Zwingend notwendig nicht, aber als normaler Anwender will man doch auch mal Zugriff auf z.B. einen USB-Stick haben um meinetwegen eine mp3 abzuspielen, also normal damit "arbeiten". Dafür muss man m.E. in den Gruppen plugdev und audio sein. Oder habe ich Dich falsch verstanden?

  • Oder habe ich Dich falsch verstanden?

    Nein, das hast Du schon richtig verstanden. ich wollte damit nur sagen, dass man evtl. nicht _alle_ anderen Gruppen (... außer sudo und pi) brauchen wird, in denen der user pi (per default) Mitglied ist oder war. Z. B.:

    Code
    :~ $ id
    uid=1000(pi) gid=1000(pi) groups=1000(pi),4(adm),20(dialout),24(cdrom),27(sudo),29(audio),44(video),46(plugdev),60(games),100(users),101(input),108(netdev),997(gpio),998(i2c),999(spi)

    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

  • Danke ThomasL für die ausführlich Erklärung! Auch an hyle und rpi444 für die Hinweise der Gruppen. Das Umstellen kling für mich machbar und kommt auf die Todo Liste. Auf jeden Fall besser als irgendwo mit Dateiattributen "rumzuspielen".

  • Es ist imho sinnvoller Tools wie Tripwire Änderungen an systemrelevanten Dateien überwachen zu lassen, als diesen Files mit chattr auf den Leib zu rücken.

    Wenn man 365 Tage im Jahr und zeitnah Zugang zu seinem PI hat oder eine Vertretung für die Dauer der Abwesenheit hat, ja.

    Denn bei solchen Tools heißt es fast immer:

    Zitat

    Änderungen werden dem Nutzer bekannt gegeben.

    bzw.

    Zitat

    Open Source Tripwire erkennt Angriffe vor allem, nachdem sie geschehen sind, ...

    Alles hat Vor- und Nachteile.

    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

  • Alles hat Vor- und Nachteile.

    *lol* genau so ist es... und im Moment scheint es mir fast wie ein Katze und Mausspiel zu sein... manche Maus wird gefressen, manche schaffens sich erfolgreich zu verstecken.

    Und wer Bock auf schlechte Laune hat, googelt mal nach PSD2-Richtlinie, was ein weiterer Schritt ist, mit dem die Datenhoheit auf uns eigenes digitales Leben ein weiteres Mal beseitigt wird.... und womit wir immer mehr und mehr entmündigt werden. Mir kommt dabei die Frage in den Sinn, was der beste Weg ist, alle unsere Anstrengungen zur Aufrechterhaltung des Datenschutzes mit einem Federstrich zu beseitigen, wie z.B. Antivirenscanner, Zugriffsmanagement, Firewalls, Isolierung, VPN, usw. usw.... alles was es dabei für uns an Schutzmechanismen gibt...?

    Der beste Weg, der alle Anstrengungen zur Farce macht, also auch diese sudo-Diskussion, ist dafür zu sorgen, dass grundsätzlich aus allen privaten Daten öffentliche Daten werden. Mit einem solchen Gesetz ist es wirklich fast Blödsinn, dass wir hier überhaupt über Datendiebstahl mit Hilfe von sudo diskutieren. Vielleicht sind wir alle "verbohrte ewig-gestrige", die noch an Werte und Schutz von Persönlichkeit und Privatsphäre glauben... Werte, die nicht im Interesse des Profits liegen, sondern einfach nur egoistisch sind.

    :conf:

  • Zitat

    Open Source Tripwire erkennt Angriffe vor allem, nachdem sie geschehen sind, ...

    Deswegen heissen die Systeme ja auch IDS und nicht IP(redicting)S. :)

    Wenn du nichts zu sagen hast, sag einfach nichts.

Jetzt mitmachen!

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