chattr - Schutz für Konfigurationsdateien mittels Setzen eines Bit

Hinweis: In dem Thema chattr - Schutz für Konfigurationsdateien mittels Setzen eines Bit gibt es 3 Antworten. Der letzte Beitrag () befindet sich ganz unten auf dieser Seite.
  • Wer mit root oder su oder sudo im System unterwegs ist, sollte vorsichtig sein mit dem, was er tut. So könnte ein unabsichtlicher Tastendruck ein höchst unerwünschtes Ergebnis zeitigen. Das gilt auch für Updates oder Upgrades, die Konfigurationsdateien verändern könnten, die man im vorliegenden Zustand belassen möchte. Hier im Forum wurde schon des öfteren bemängelt, das ein Upgrade oder Update eine Datei unerwünschterweise verändert hat. Da kann man ganz einfach Abhilfe schaffen, indem man die entsprechende Datei durch ein zusätzliches Bit vor Veränderungen schützt. In allen Linux-Varianten ist das Tool chattr vorhanden.

    Zur Benutzung geben wir im Terminal ein:


    Als Root

    Code
    chattr +i /zu/schützende/Datei

    Durch dieses sogenannte Immutable-Attribut ist es selbst Root untersagt, die Datei zu ändern, ehe man nicht die Immunität mit

    Code
    chattr -i /zu/rückzusetzende/Datei

    aufgehoben hat.


    Root oder SUDO Konten haben natürlich weiterhin Zugriff auf die Datei, jedoch sind Flüchtigkeitsfehler oder fehlerhafte Installationsscripts aussen vor.

  • Ich möchte das noch etwas ergänzen. Es gibt auch in der Benutzer-Hierarchie Verzeichnisse und Dateien, die z. B. für Schadsoftware interessant sind, weil sie sich dort einpflanzen könnte und Bootvorgänge überstehen könnte, obwohl sie dabei nur Benutzerrechte hat. Stichwort Ransomware.


    Deshalb nutze ich nicht einfach chattr, sondern sudo chattr. So kann eine Schadsoftware das Immutable Bit nicht einfach zurücksetzen, wenn sie nur über Benutzerrechte verfügt. Dabei setze ich voraus, dass man nur ausnahmsweise als root unterwegs ist, jedenfalls handele ich grundsätzlich so.


    Grundsätzlich schütze ich für meinen Benutzer stets


    Code
    ~> sudo chattr -R +i ~/bin
    ~> sudo chattr -R +i ~/.config/autostart
    ~> sudo chattr -R +i ~/.config/autostart-scripts
    ~> sudo chattr +i ~/.bashrc


    Im ~/bin stehen meine eigenen bash Scripte, das wäre ein Ort wo ein Schädling etwas austauschen könnte, was ich dann arglos ausführe.

    In den autostart Pfaden könnte sich etwas einpflanzen und nach dem nächsten Bootvorgang seine Aktivitäten erneuern/erweitern/ $sonstwas tun

    Und mit Alias-Einträgen in der .bashrc könnten ganz andere Binaries aktiviert werden, als die , die aufzurufen glaubt.


    Aber Achtung: .bashrc und die autostart Pfade können durch weitgehende Systemupdates das Immutable Bit wieder verlieren.

    Es empfiehlt sich daher, das gelegentlich zu überprüfen!

  • Anmerkung:

    So kann eine Schadsoftware das Immutable Bit nicht einfach zurücksetzen, wenn sie nur über Benutzerrechte verfügt.

    Eine Schadsoftware kann das Bit nicht zurück setzen, weil sie nicht über Root-Rechte verfügen kann. Es sei denn, der User ist mit Root-Rechten im System unterwegs. Das wäre dann ein klarer Fall von selbst dran Schuld.

    Ein Setzen des Bit als User ist nicht möglich, deshalb schrieb ich auch ... als Root ...

    Versucht man das dennoch, bekommt man folgende Aussage

    Code
    chattr: Die Operation ist nicht erlaubt beim Setzen der Flags in /home/karsten/Vorlagen/Textdatei.txt

    Welche Dateien man damit schützt ist jedem selbst überlassen. Das ein Update dieses Bit überschreibt und die zu schützende Datei freigibt ist so gut wie ausgeschlossen.

    Ich habe mit der geschützten Datei so ziemlich alles versucht, was auch nur möglich ist.


    Ein hineinkopieren einer anderen Datei mit selbem Namen und leicht geändertem Inhalt - Ergebnislos

    Ein Löschen als User - Ergebnislos

    Ein Überschreiben als User - Ergebnislos


    All das als Root - Ergebnislos

    Auch ein Löschen oder Überschreiben oder sonstwie verändern als Root - Ergebnislos

    Somit ist die Datei auch vor einem Update geschützt.

    Selbst eine Neuinstallation sollte zu keinem Ergebnis führen, was ich natürlich jetzt nicht testen werde. »³


    Fazit: Oben angeführtes Zitat verweist auf einen unmöglichen Zustand.

  • Ich habe aber bereits mindestens 2xerlebt, dass bei den o. g. autostart-Verzeichnissen und der .bashrc das I-Bit plötzlich verschwunden war. Ich hatte das ganz sicher nie getan. Dass dies durch Updates passierte, ist allerdings nur eine Vermutung von mir, weil ich es mir anders nicht erklären kann.