Wie löscht man denn eigentlich sicher die Bash History von root? Ist die Datei /root/.bash_history eigentlich verschlüsselt?
Bash History von root sicher löschen?
Anmeldungsdatum: Beiträge: 873 |
|
Anmeldungsdatum: Beiträge: 7658 |
Wieso soll die verschlüsselt sein? Zumal Verschlüsselung mit bekanntem Schlüssel witzlos ist, die Bash muss ja wissen wie das entschlüsselt wird. Nein, das wird über Dateirechte geregelt, in /root/ darf nur root lesen und fertig und die .bash_history selbst wird auch mit minimalen Rechten angelegt (0600) Wenn du keine History haben willst - die kann man auch ganz abstellen. Was gar nicht erst erzeugt wird muss anschließend auch nicht sicher gelöscht werden. Oder du verlegst sie in ein tmpfs das nach dem Reboot fort ist, dann hast du wenigstens eine History solange die Kiste läuft. |
Anmeldungsdatum: Beiträge: 1816 |
... und die bestehende History kann man exakt auf demselben Wege sicher löschen, wie man jede andere Datei auch sicher löschen kann. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 873 |
Ok, jetzt hab ich irrtümlich zur falschen Zeit in Klartext im Root-Terminal mein sudo Passwort eingegeben (Shift+Strg+V). Kann ich (sollte ich) die Datei /root/.bash_history mit wipe oder shred sicher löschen? Edit: Danke für eure Hilfe! Beitrag von unbuntuS12 erst danach entdeckt... |
Anmeldungsdatum: Beiträge: 1816 |
Wenn du den Rest deiner History behalten willst und gleichzeitig das Passwort sicher löschen willst, kanns du als root die Datei in einem Editor öffnen, die fragliche Zeile entfernen. Dann speichern und schließen, dann die Datei kopieren, z. B. # cp /root/.bash_history /root/.bash_history.bak Dann die alte Datei löschen: shred /root/.bash_history Und die alte Datei zurückkopieren: # cp /root/.bash_history.bak /root/.bash_history |
Anmeldungsdatum: Beiträge: 7658 |
In der noch laufenden Shell sollte Btw., beginnt man mit einem Leerzeichen, landet der Befehl nicht in der History. $ echo das ist normal $ echo das ist geheim $ history 3 echo das ist normal 4 history |
Anmeldungsdatum: Beiträge: 1816 |
Na ja, um sie zu löschen, aber nicht, um sie sicher zu löschen im Sinne von Überschreiben.
Dazu müsste man auch den ganzen Beitrag lesen ... edit: OK, elegant ist trotzdem was anderes. Schöner wäre head -n -1 /root/.bash_history > /root/.bash_history.bak dann shredden, dann zurückkopieren. Trotzdem sind das alles Spielereien, so lange man das konkrete Angriffsszenario nicht kennt, bzw. nicht drüber spricht. |
Anmeldungsdatum: Beiträge: 7658 |
Wird in deinem Beispiel auch nicht gemacht.
$ history -c $ ls -l .bash_history -rw------- 1 andreas andreas 11200 Sep 26 16:18 .bash_history
Hab ich, bleibt leider genauso sinnlos wie vorher. In dem Moment wo du mit einem Editor speicherst, hast du eine neue Datei, die physikalisch woanders liegt, und shred macht an der alten die du sicher löschen wolltest sicher nichts mehr. Was du machen kannst ist .bash_history mit dem Editor bearbeiten, unter einem anderen Namen speichern (.bash_history.editiert), und dann .bash_history shredden und .editiert umbenennen. Dann würde das vielleicht anfangen irgendwie Sinn zu machen. Am Ende bleibt doch nur den freien Speicher komplett zu tilgen oder aber sich einfach keinen Kopf drum zu machen, zumal in diesem Fall:
es wirklich wurscht ist. sudo passwort. Wer an deine .bash_history kommt, der braucht das sowieso nicht mehr. |
Anmeldungsdatum: Beiträge: 1816 |
Solange es sich nicht um ein Copy-on-Write-Dateisystem handelt und ich unterm demselben Namen speichere, sollte genau das nicht der Fall sein. Dann kann nur der Fall eintreten, dass durch das Löschen einer Zeile im Editor ein Block weniger benötigt wird, der dann tatsächlich mit shred nicht gelöscht werden würde. Mit meiner zweiten Variante besteht aber dieses Minimalrisiko nicht.
Genau, deshalb mein Hinweis auf das Anwendungsszenario. Wurscht wäre es nur dann nicht, wenn jemand physischen Zugang zur unverschlüsselten Platte hätte. |
Anmeldungsdatum: Beiträge: 12067 |
Anderer Ansatz: Entferne das PW wie beschrieben per Editor und vergib dann ein Neues ☺ btw: frostschutz schrieb:
|
Anmeldungsdatum: Beiträge: 7658 |
Stinknormales Dateisystem. (XFS) # filefrag -v -e .bash_history Filesystem type is: 58465342 File size of .bash_history is 10748 (3 blocks of 4096 bytes) ext: logical_offset: physical_offset: length: expected: flags: 0: 0.. 2: 148745.. 148747: 3: last,eof .bash_history: 1 extent found # vim .bash_history :x [Speichern] # filefrag -v -e .bash_history Filesystem type is: 58465342 File size of .bash_history is 10748 (3 blocks of 4096 bytes) ext: logical_offset: physical_offset: length: expected: flags: 0: 0.. 2: 110036.. 110038: 3: last,eof .bash_history: 1 extent found Das gleiche mit ext2: 0: 0.. 1: 1025.. 1026: 2: last,merged,eof 0: 0.. 1: 1027.. 1028: 2: last,merged,eof 0: 0.. 1: 2049.. 2050: 2: last,merged,eof 0: 0.. 1: 2051.. 2052: 2: last,merged,eof Einzige Datei im Datiesystem, verschiedene Editoren, unverändert gespeichert, die physikalische Adresse wandert... Speichern ist nicht in-place. Da wird immer die komplette Datei neu geschrieben. Gleicher Name, möglicherweise völlig andere physikalische Adresse. Mal davon abgesehen daß viele Editoren nochmal ihre eigenen Arbeitskopien erstellen. Deswegen braucht es ja spezielle Software ( Zu shred gibts eine Grundregel, wenn du meinst damit was sicher gelöscht zu haben, ist das zu 99% nicht der Fall. Dazu werden zu oft ungefragt Kopien erstellt, von denen das Dateisystem selber nichts mehr weiss. Gesamtes Gerät oder freien Speicher überschreiben oder fstrim/discard, alles andere ist Augenwischerei. |
Anmeldungsdatum: Beiträge: 1816 |
Danke für die Klarstellung. 👍 Ich bin tatsächlich vom Gegenteil ausgegangen. Vor dem Hintergrund kann ich verstehen, dass mein erster Vorschlag wenig Sinn ergab. |
Anmeldungsdatum: Beiträge: 779 Wohnort: Görlitz |
Wo ist das Problem? Wer root benutzen kann, kennt eh das PW. Wenn das noch mal irgendwo rumsteht, aber nur mit root einsehbar ist, was soll's. Anders schaut es aus, wenn man mit sudo -s root geworden ist. Da ist die History auch vom dem User lesbar, von dem aus man sudo -s getippt hat. Ausnahme ist ein SSH Zugang per Key zum root. Aber davon solle man ohnehin die Finger lassen. Einfaches Löschen des falschen Eintrags in der History mit vim reicht. Der User hat als User eh nicht die Mittel, um ein Recovery alter gelöschter Files zu machen. Dazu braucht er root und damit das PW. Gruss |