DAU-Sicherung für Linux/Windows, damit auch mit dd spielende root-User nichts kaputt machen

[Rolf F. (Firma: G.) (benutzername0)]

Nachdem sich zeigte das ein User, als root, auf eine Platte mit dd 
geschrieben hat und diese Platte "zufälligerweise" die Systemplatte ist 
(mit dem Bootloader, Wurtelverzeichnis und Swap-Partition), suche ich 
eine DAU-Sicherung, hauptsächlich für Linux, aber möglichst auch für 
Cygwin unter Windows, denn da hat man auch dd.
Eine Möglichkeit wäre Installieren auf einem USB-Stick mit 
Schreibschutzschalter oder ein Live-System auf DVD/CD aber zum Arbeiten 
muss auch mal etwas gespeichert werden, z. B. Image-Dateien, aber damit 
gibt es einen Datenträger den man mit dd kaputt bekommt.
Gibt es dazu Alternativen, beispielsweise eine dd-Version die nichts 
gemountetes überschreibt?

[c.m. (Gast)]

geht vielleicht mit selinux, aber das eigentliche problem ist:

ein User, als root

[Rolf F. (Firma: G.) (benutzername0)]

c.m. schrieb:
> geht vielleicht mit selinux, aber das eigentliche problem ist:
>

> ein User, als root

Ja, ich weiß, aber es sollen auch Platten mit Null überschriebenn 
werden, beispielsweise damit ein Image davon, nach einer nachfolgenden 
Installation, möglichst gut komprimiert werden kann.

[g457 (Gast)]

> Eine Möglichkeit wäre Installieren auf einem USB-Stick mit
> Schreibschutzschalter oder ein Live-System auf DVD/CD [..]

Noch besser: Booten übers Netz und Dateisystem über nfs.

[dd (Gast)]

dd umbenennen

[olibert (Gast)]

Rolf F. schrieb:
> Ja, ich weiß, aber es sollen auch Platten mit Null überschriebenn
> werden, beispielsweise damit ein Image davon, nach einer nachfolgenden
> Installation, möglichst gut komprimiert werden kann.

Wrapper Script fuer dd und sudo, fertig.

[c.m. (Gast)]

Rolf F. schrieb:
> c.m. schrieb:
>> geht vielleicht mit selinux, aber das eigentliche problem ist:
>>

>> ein User, als root

>
> Ja, ich weiß, aber es sollen auch Platten mit Null überschriebenn
> werden, beispielsweise damit ein Image davon, nach einer nachfolgenden
> Installation, möglichst gut komprimiert werden kann.

unnötig, weil geeignete backupprogramme (z.b. clonezilla) nicht ganze 
partitionen dumpen und komprimieren, sondern nur vom dateisystem 
benutzte bereiche.

probiers mal :)

[Dirk D. (dicky_d)]

Rolf F. schrieb:
> c.m. schrieb:
>> geht vielleicht mit selinux, aber das eigentliche problem ist:
>>

>> ein User, als root

>
> Ja, ich weiß, aber es sollen auch Platten mit Null überschriebenn
> werden, beispielsweise damit ein Image davon, nach einer nachfolgenden
> Installation, möglichst gut komprimiert werden kann.

Wenn du wirklich das komplette device sichern willst statt nen tool zu 
nutzen das das dateisystem versteht geht das aber trotzdem ohne DD
du kannst die nullen auch einfach ins dateisystem schreiben, vorm 
sichern.
das image ist dam im besten fall sogar besser komprimierbar als das 
vorher genullte, weil die blocks die zwischenzeitlich daten gefüllt 
waren, es aber nicht mehr sind, auch genullt werden.

das machst du relativ einfach mit
cat /dev/zero >/pfad/in/das/zu/sichernde/dateisystem
rm /pfad/in/das/zu/sichernde/dateisystem

Danach ist dein gezipptest image maximal so groß wie df dir als belegt 
anzeigt.

[Erwin M. (nobodyy)]

c.m. schrieb:
> unnötig, weil geeignete backupprogramme (z.b. clonezilla) nicht ganze
> partitionen dumpen und komprimieren, sondern nur vom dateisystem
> benutzte bereiche.

Das hilft nicht generell, denn Clonezilla kann nicht auf alle 
Dateisysteme zugreifen, beispielsweise verschlüsselte oder 
steganografische, und beim Klonen mit dd überträgt auch MBR/GPT und auch 
den Bootloader - auch für die exotischsten Betriebssyteme.

[Possetitjel (Gast)]

Rolf F. schrieb:

> c.m. schrieb:
>> geht vielleicht mit selinux, aber das eigentliche problem ist:
>>
>>> ein User, als root

> Ja, ich weiß,

Offenbar doch nicht.

> aber es sollen auch Platten mit Null überschriebenn
> werden, [...]

Ja und?

Ich würde versuchen, das über die Zugriffsrechte zu regeln,
also:
- verhindern, dass sich der User als root einloggt,
- den User in eine eigens dafuer angelegte Gruppe stecken,
- die Group-ID der gewuenschten Devices auf diese Gruppe setzen,
- dafuer sorgen, dass die Gruppe Schreibrecht hat.

Ggf. muss man noch dafür sorgen, dass das nicht mit der
systemeigenen Gruppe kollidiert. -- Habe das aber noch nicht
selbst gemacht; kann sein, dass ich Fallstricke übersehe...

[oszi40 (Gast)]

Rolf F. schrieb:
> Gibt es dazu Alternativen

Regelmäßige Images an einem sichern Ort (Schrank) aufbewahren, sollte 
der erste Schritt gegen allerlei Datenverlust sein.

Rolf F. schrieb:
> Gibt es dazu Alternativen, beispielsweise eine dd-Version die nichts
> gemountetes überschreibt?

Du bist nie sicher, daß ein DAU eine gewünschte Version benutzt. Wenn 
das LW auf einem anderen Rechner liegt, wo der DAU keine Schreibrechte 
bekommt und kein Admin ist, wird er wenig löschen können.

[Julian .. (juliank)]

Relax-and-Recover

Wird aber dein eigentliches Problem nicht lösen.
Wenn der Lerneffekt wirkt, ok. Wenn nicht root abnehmen
und das über user/gruppen rechte regeln (udev kann das).

[Gerd E. (robberknight)]

Rolf F. schrieb:
> Ja, ich weiß, aber es sollen auch Platten mit Null überschriebenn
> werden, beispielsweise damit ein Image davon, nach einer nachfolgenden
> Installation, möglichst gut komprimiert werden kann.

bei SSDs ist das keine tolle Idee: nach dem Schreiben der Nullen denkt 
die SSD daß der Block belegt ist und nimmt den aus der Liste der Freien 
raus. Das macht sie langsamer.

Dein Komprimier- und vor allem Dein Entkomprimierprogramm sollten also 
besser wissen wo echte Daten sind und wo nicht.

Wenn die Partitionen verschlüsselt sind, dann den Inhalt in 
unverschlüsseltem Zustand komprimieren und diesen dann wieder 
verschlüsseln. Den Inhalt einer bereits verschlüsselten Partition kannst 
Du nämlich sowieso nicht mehr komprimieren.

[Siggi (Gast)]

Julian .. schrieb:
> Relax-and-Recover
>
> Wird aber dein eigentliches Problem nicht lösen.
> Wenn der Lerneffekt wirkt, ok. Wenn nicht root abnehmen
> und das über user/gruppen rechte regeln (udev kann das).

Das geht auch mit dd als nicht-root.
dd if=/dev/zero of=~/nullfile bs=32768

Das Ding laufen lassen bis kein Speicherplatz mehr frei ist. Mit 
bs=32768 muß Du rumprobieren was am schnellsten geht. Wenn Du bs= 
wegläßt, wird als Blockflöte 512 Bytes genommen. Das dauert.
Dann das nullfile einfach löschen und auf der Partition auf der sich das 
Home-Verzeichnis befindet ist der gesamte freie Platz mit Nullen 
gefüllt.
Das funktioniert auch mit SDD und  verschlüsselung.

[Siggi (Gast)]

Blockflöte -> Blockgröße

Was für eine bescheuerte "Smart"phone Mimik.

[Dirk D. (dicky_d)]

Gerd E. schrieb:
> Rolf F. schrieb:
>> Ja, ich weiß, aber es sollen auch Platten mit Null überschriebenn
>> werden, beispielsweise damit ein Image davon, nach einer nachfolgenden
>> Installation, möglichst gut komprimiert werden kann.
>
> bei SSDs ist das keine tolle Idee: nach dem Schreiben der Nullen denkt
> die SSD daß der Block belegt ist und nimmt den aus der Liste der Freien
> raus. Das macht sie langsamer.
Deswegen lösch ich das file ja auch hinterher wieder :/

[Daniel A. (daniel-a)]

Ich würde da anders vorgehen. Wenn man wirklich ein bootbares 
komplettimage braucht, würde ich sowas versuchen. Ich habe das jetzt 
aber nicht getestet:

#!/bin/sh

disk=/dev/sda   # source device
image=test.img  # destination image
mountpoint1=/mnt/backuptmp1 # temporary mountpoint disk
mountpoint2=/mnt/backuptmp2 # temporary mountpoint image
ddparts="1 2"   # partition numbers to dd
ext4cp="4"      # ext4 partition numbers to copy

size=$(blockdev --getsize64 "$disk") # Grösse von $disk
truncate -s "$size" "$image"         # sparseimage mit grösse size, das keinen Speicher belegt (sofern vom Dateisystem unterstützt)
sgdisk -P "$device" -R "$image"      # (GPT) Partitionstabelle kopieren

loop=$(losetup -Pf --show "$image")  # Create loop device & setup image partition block devices
if [ $? != 0 ] # abord on error
then
  rm "$image"
  echo "Error: losetup failed"
  exit 1
fi

for i in $ddparts  # copy some small partitions, z.B. boot & efi
  do dd if="$disk$i" of="$loop"p"$i"
done

mkdir -p "$mountpoint1" # verzeichnis für mountpoint erstellen
mkdir -p "$mountpoint2" # verzeichnis für mountpoint erstellen

for i in $ext4cp
do
  mkfs.ext4 "$loop"p"$i"  # create ext4 filesystem in image/loopdevice partition
  mount -r -o ro "$disk$i" "$mountpoint1" # Platte mounten
  mount "$loop"p"$i" "$mountpoint2"       # image partition mounten
  cp -a "$mountpoint1"/. "$mountpoint2"   # Alles kopieren
  umount "$mountpoint1"                   # platte unmounten
  umount "$mountpoint2"                   # image partition unmounten
done

losetup -D "$loop" # loopdevice freigeben
gzip "$image" # image gzippen

Könnte natürlich noch etwas error handling vertragen.

[Rolf F. (Firma: G.) (benutzername0)]

Possetitjel schrieb:

> - verhindern, dass sich der User als root einloggt,
> - den User in eine eigens dafuer angelegte Gruppe stecken,
> - die Group-ID der gewuenschten Devices auf diese Gruppe setzen,
> - dafuer sorgen, dass die Gruppe Schreibrecht hat.

Ja, ein guter Ansatz, aber leider gibt es auch mal die Konfiguration das 
neben der SATA-HDD als Systemplatta auch eine SCSI-HDD oder IDE-HDD 
angeschlossen und dann ist die Systemplatte nicht sda sondern sdb oder 
sdc.
Damit bleibt wohl erstmal nur ein DVD-Laufwerk und USB-Sticks als 
Wechseldatenträger.

[Andreas R. (daybyter)]

Virtualbox und VM regelmässig exportieren + Backup an sicherem Ort.

[c-hater (Gast)]

Rolf F. schrieb:

> Ja, ich weiß, aber es sollen auch Platten mit Null überschriebenn
> werden, beispielsweise damit ein Image davon, nach einer nachfolgenden
> Installation, möglichst gut komprimiert werden kann.

Dann baut man eine "Anwendung" (hier reicht wohl ein sehr primitives 
bash-Script), die genau dies (und nix anderes) tut und gibt den Usern, 
die das machen müssen, genau nur das Recht, diese eine Anwendung mit 
root-Rechten auszuführen. Für alles andere bleiben sie das, was sie sein 
sollen: poplige Standard-User.

man sudo (und Verweise)

Anmerkung: wenn man dir das erst erklären muss, bist du genauso unfähig 
wie diese User. Du solltest ebenfalls keine root-Rechte haben...

Bleibt die Frage: Hast du die bei einem Schönheitswettbewerb gewonnen 
oder im Lotto?

[Possetitjel (Gast)]

Rolf F. schrieb:

> Possetitjel schrieb:
>
>> - verhindern, dass sich der User als root einloggt,
>> - den User in eine eigens dafuer angelegte Gruppe stecken,
>> - die Group-ID der gewuenschten Devices auf diese Gruppe setzen,
>> - dafuer sorgen, dass die Gruppe Schreibrecht hat.
>
> Ja, ein guter Ansatz, aber leider gibt es auch mal die Konfiguration
> das neben der SATA-HDD als Systemplatta auch eine SCSI-HDD oder
> IDE-HDD angeschlossen und dann ist die Systemplatte nicht sda
> sondern sdb oder sdc.

Das ist natürlich Scheisse.

> Damit bleibt wohl erstmal nur ein DVD-Laufwerk und USB-Sticks als
> Wechseldatenträger.

Nicht zwingend. Unter der Annahme, dass sich die Systemplatte nicht
im laufenden Betrieb ändert, könnte man ein Boot-Script basteln, das
die Schreibrechte passend setzt.

Natürlich... "schön" geht anders...

[Daniel A. (daniel-a)]

Possetitjel schrieb:
> Nicht zwingend. Unter der Annahme, dass sich die Systemplatte nicht
> im laufenden Betrieb ändert, könnte man ein Boot-Script basteln, das
> die Schreibrechte passend setzt.

Dafür gibt es udev, btw. die diversen udev ersätze unter nicht systemd 
systemen.

[Oliver S. (phetty)]

Suicide Linux installieren

[Lukey S. (lukey3332)]

udev Regel für USB/eSATA Sticks/Platten erstellen, die auch nicht-root 
Usern den (voll-) zugriff erlaubt.

[Rolf M. (rmagnus)]

Siggi schrieb:
> Das Ding laufen lassen bis kein Speicherplatz mehr frei ist. Mit
> bs=32768 muß Du rumprobieren was am schnellsten geht. Wenn Du bs=
> wegläßt, wird als Blockflöte 512 Bytes genommen. Das dauert.
> Dann das nullfile einfach löschen und auf der Partition auf der sich das
> Home-Verzeichnis befindet ist der gesamte freie Platz mit Nullen
> gefüllt.

Dann musst du aber ein Dateisystem benutzen, das noch keine Sparse Files 
kennt. Bei dem werden die Nullen nämlich einfach "wegoptimiert".

> Das funktioniert auch mit SDD und  verschlüsselung.

Glaube nicht, dass das mit Verschlüsselung funktioniert. Es würde 
Angriffspotenzial bieten, wenn verschlüsselte Nullen auch wieder Nullen 
wären.

Siggi schrieb:
> Blockflöte -> Blockgröße
>
> Was für eine bescheuerte "Smart"phone Mimik.

Das erste, was man macht, ist doch, diese dämliche Automatik 
abzuschalten.

Dirk D. schrieb:
>> bei SSDs ist das keine tolle Idee: nach dem Schreiben der Nullen denkt
>> die SSD daß der Block belegt ist und nimmt den aus der Liste der Freien
>> raus. Das macht sie langsamer.
> Deswegen lösch ich das file ja auch hinterher wieder :/

Dazu muss die SSD aber auch mitkriegen, dass die Nullen, die gerade noch 
zu einer Datei gehörten, jetzt als unbelegt gelten sollen.

Andreas R. schrieb:
> Virtualbox und VM regelmässig exportieren + Backup an sicherem Ort.

Bzw gleich mit Snapshots arbeiten.

[Dirk D. (dicky_d)]

Rolf M. schrieb:
> Siggi schrieb:
>> Das Ding laufen lassen bis kein Speicherplatz mehr frei ist. Mit
>> bs=32768 muß Du rumprobieren was am schnellsten geht. Wenn Du bs=
>> wegläßt, wird als Blockflöte 512 Bytes genommen. Das dauert.
>> Dann das nullfile einfach löschen und auf der Partition auf der sich das
>> Home-Verzeichnis befindet ist der gesamte freie Platz mit Nullen
>> gefüllt.
>
> Dann musst du aber ein Dateisystem benutzen, das noch keine Sparse Files
> kennt. Bei dem werden die Nullen nämlich einfach "wegoptimiert".

ich weiß nicht wie es wo anders ist, unter linux sind sparse files 
solche bei denen bereiche NICHT beschrieben sind, das unterscheidet sich 
deutlich von bereichen die mit nullen gefüllt sind.

Technisch geht das so:

file = fopen('file','w');
fseek(file , 1024*1024*1024, SEEK_SET);
fclose(file);

Jetzt hab ich nen sparse-file mit nem gb.
wenn ich einfach nullen in ne datei schreibe habe ich ne datei mit 
nullen.


> Dirk D. schrieb:
>>> bei SSDs ist das keine tolle Idee: nach dem Schreiben der Nullen denkt
>>> die SSD daß der Block belegt ist und nimmt den aus der Liste der Freien
>>> raus. Das macht sie langsamer.
>> Deswegen lösch ich das file ja auch hinterher wieder :/
>
> Dazu muss die SSD aber auch mitkriegen, dass die Nullen, die gerade noch
> zu einer Datei gehörten, jetzt als unbelegt gelten sollen.

Das geht ja seid 8 Jahren, ab Kernel 2.6.28.

[Andreas M. (amesser)]

Rolf F. schrieb:
> Possetitjel schrieb:
>
>> - verhindern, dass sich der User als root einloggt,
>> - den User in eine eigens dafuer angelegte Gruppe stecken,
>> - die Group-ID der gewuenschten Devices auf diese Gruppe setzen,
>> - dafuer sorgen, dass die Gruppe Schreibrecht hat.
>
> Ja, ein guter Ansatz, aber leider gibt es auch mal die Konfiguration das
> neben der SATA-HDD als Systemplatta auch eine SCSI-HDD oder IDE-HDD
> angeschlossen und dann ist die Systemplatte nicht sda sondern sdb oder
> sdc.
> Damit bleibt wohl erstmal nur ein DVD-Laufwerk und USB-Sticks als
> Wechseldatenträger.

Und? Man kann mit udev auch auf z.B. Seriennummern vergleichen. Aber wie 
schon gesagt, einfach ein Wrapper Skript, welches die notwendigen 
Arbeitsbefehle im Bauch hat und von den Nutzern per sudo ausgeführt 
werden kann. Für ein solches Skript ist es ein leichtes zu prüfen ob das 
übergebene /dev/sdX die Systemplatte ist oder nicht.

Ich vermute eher die Nutzer wollen Ihre root-rechte nicht abgeben...

[Planlos (Gast)]

>> [...] dd if=/dev/zero of=~/nullfile bs=32768
oder
>> [...] cat /dev/zero >/pfad/in/das/zu/sichernde/dateisystem ; rm 
/pfad/in/das/zu/sichernde/dateisystem


> Dazu muss die SSD aber auch mitkriegen, dass die Nullen, die gerade noch
> zu einer Datei gehörten, jetzt als unbelegt gelten sollen.


fstrim -v /<mountpoint>

macht bei SSDs dasselbe in einem Rutsch, unbelegte Blöcke per TRIM 
freigeben.

Mit hdparm -I /dev/sdX die SSD prüfen, wenn da das Flag:
* Deterministic read ZEROs after TRIM
gesetzt ist, dann sind die Blöcke nachher auch alle genullt.

[Erwin M. (nobodyy)]

Andreas M. schrieb:
> Aber wie
> schon gesagt, einfach ein Wrapper Skript, welches die notwendigen
> Arbeitsbefehle im Bauch hat und von den Nutzern per sudo ausgeführt
> werden kann. Für ein solches Skript ist es ein leichtes zu prüfen ob das
> übergebene /dev/sdX die Systemplatte ist oder nicht.

Ja, die Ausgabe von mount zu durchsuchen, und zu prüfen ob es das 
Block-Device auch gibt, ist ja nicht schwer.
Dazu habe ich ein Skript gemacht, für die Leute die das nicht können 
(auch Kindersicherung genannt).