Von daher finde ich Tools wie die in Gnome eingebaute Funktion zum Flashen von ISOs oder Tools wie Etcher von der Idee sehr gut. Über die grafische Oberfläche hat man als Nutzer doch ein wenig mehr Übersicht und Kontrolle. Die Laufwerksverwaltung von Gnome versteckt die Funktion zum Flashen von ISOs allerdings recht gut und bei Etcher stoße ich mich an Electron. Auch wenn es für Entwickler praktisch sein mag: Nur dafür einen zig MByte großen und per se nutzlosen Software-Blob auf das System zu spülen, finde ich doch ein wenig übertrieben.

Für Nutzer von KDE Plasma gibt es als Alternative den ISO Image Writer. Das Programm fügt sich sauber in die Desktopumgebung ein und trägt nicht sonderlich dick auf. Für Gnome gab es ein solch kleines Programm bisher nicht. Bisher. Seit ein paar Tagen gibt es mit Impression (Github, Flatpak) eine moderne Option auf Basis von GTK4 zum Schreiben von ISO-Images für Anhänger von GTK-Desktops. Die Bedienung ist einfach: Programm starte, ISO-Image und Ziel auswählen, Image schreiben, Fertig. Fehler können hier nicht passieren, da Impression nur USB-Sticks und Speicherkarten, aber keine Festplatten als Zielort anbietet.

Aktuell findet ihr Impression noch nicht in den Paketquellen der üblichen Linux-Distributionen. Via Flatpak klappt die Installation allerdings problemlos. Der Versionszähler der Anwendung steht gerade bei 1.0.0 und der Quellcode ist erst seit ein paar Tagen online, auch die Übersetzung ins Deutsche fehlt noch. Das wird sich aber sicherlich schnell ändern. Und es dauert sicherlich nicht lange, bis Gnome das Projekt in seinen stetig wachsenden Gnome Circle aufnimmt und ihm so deutlich mehr Bekanntheit liefert.

Um sich dabei ein wenig Zeit zu sparen, konnte man auf Evo/Lution bauen. Dieses auf einem Arch basierenden Live-Linux konnte Arch über eine grafische Installationsroutine installieren, doch das dadurch recht starre Korsett wurde den Möglichkeiten von Arch nicht gerecht. Daher hat der Entwickler von Evo/Lution nun umgesattelt und steckt seine Energie in Architect Linux (Forum, GitHub oder Google+) beziehungsweise in das Architect Installation Framework. Dieses erlaubt mit einem textbasierten Setup die Installation von Arch, ohne dass man sich vorher durch mehrere Seiten Text wühlen müsste.

Architect bekommt ihr über Sourceforge als ganz gewöhnliche ISO-Datei (hier der Link zur jeweils aktuellen 64-Bit-Version) — auf der Sourceforge-Seite bekommt ihr Architect auch in einer Variante für 32-Bit-Systeme. Diese schreibt ihr wie andere Linux-Distributionen auf eine DVD oder besser gleich einen USB-Stick und bootet das Systems. Im Bootmanager habt ihr dann die Wahl zwischen den Punkten Boot Architect Linux und Boot existing OS, mit der ersten Option ladet ihr den Arch-Installer. Nach einer kurzen Initialisierung lädt Architect die letzte Version des Installer-Frameworks aus dem Netz und beginnt mit der Installation.

Bei der Auswahl der Sprache müsst ihr euch aktuell noch mit Englisch (oder einer Reihe anderer Sprachen) begnügen. Der Ticker für die Deutsche Übersetzung steht bei Transifex (einem Portal für die Übersetzung von Software) noch bei Null Prozent — hier bietet sich der Arch-Community daher schon mal ein Weg an, dem Projekt unter die Arme zu greifen. Ansonsten hangelt ihr euch von Punkt 1 bis 9 durch die Menüs. Wie üblich bereitet ihr zuerst die Partitionen auf, installiert und konfiguriert dann das Grundsystem, wählt einen Bootloader aus, spielt Treiber und Binary-Blogs für Grafikkarten oder WLAN-Adapter ein und wählt am Ende eine Desktopumgebung wie Gnome, KDE oder eine der anderen Spielarten zur Installation aus. Im letzten Schritt könnt ihr alle von Architect angelegten Konfigurationsdateien noch einmal ansehen und bearbeiten.

Wer jetzt nicht ganz grün hinter den Linux-Ohren ist, der bekommt Arch mit Architect recht schnell und ohne große Recherche installiert. Da der Installer allerdings nur wenig Beschreibungen, Hinweise oder gar Bilder gibt, werden Einsteiger auch mit Architect noch ein paar Hürden überwinden müssen — Mit ein wenig Recherche im Netz lassen sich diese aber in der Regel recht einfach lösen. Wer nun aber weiß welches Dateisystem, welcher Bootloader, welcher Displaymanager und welche Desktopumgenung auf der Platte landen soll, der spart mit Architect bei der Installation von Arch viel Zeit — ohne dass man bei der Wahl der Komponenten eingeschränkt wäre.

Zum Schreiben eines ISO-Images einer Linux-Distribution auf einen USB-Stick wird gerne die eierlegenden Wollmilchsau UNetbootin empfohlen. Es „brennt“ nicht nur auf der Platte liegende ISOs auf den USB-Stick, es lädt auf Wunsch auch eine ganze Reihe von Distributionen aus dem Netz und schiebt sie auf den USB-Stick. So spart man sich auch noch das manuelle Herunterladen der ISO-Datei.

ISO-Image mit dd auf USB-Stick schreiben

UNetbootin ist generell nicht schlecht — gerade wenn man aktuell nur ein Windows installiert hat — aber wozu unter Linux ein umfangreiches Programm installieren, wenn man mit dd doch schon das nötige Werkzeug auf der Platte liegen hat. Die größte Hürde ist dabei herauszufinden, unter welche Geräte-ID der USB-Stick anzusprechen ist: Dabei hilft einem aber das Kommando lsblk.

$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 59,6G 0 disk
├─sda1 8:1 0 53,7G 0 part /
└─sda2 8:2 0 5,9G 0 part [SWAP]
sdb 8:16 0 596,2G 0 disk
└─sdb1 8:17 0 596,2G 0 part /home
sdg 8:96 1 2G 0 disk
├─sdg1 8:97 1 794M 0 part /run/media/user/usb-stick
└─sdg2 8:98 1 31M 0 part
sr0 11:0 1 1024M 0 rom

Blkid listetet die am Rechner hängenden Blockgeräte — also Festplatten, CD/DVD-ROMs und eben USB-Sticks — als Baum mitsamt der Größe des Speichers auf. So habt ihr schnell das richtige Gerät herausgesucht, ohne dass ihr euch durch die Logs von dmesg oder /var/log/messages graben müsstet — Der Mount-Punkt hängt natürlich von dem Namen ab, den ihr der Partition des Sticks verpasst habt.

$ sudo dd if=/pfad/zu/beispiel.iso of=/dev/sdg; sync

Das Schreiben des ISO-Images übernimmt dann ein Aufruf von dd. Wichtig ist hier vor allen Dingen, dass man den USB-Stick als Ziel angibt. Tut man dies aufgrund einer Verwechselung nicht, dann drohen Datenverluste! Diverse Seiten empfehlen beim Schreiben des ISOs eine bestimmte Block-Größe wie bs=1024K oder bs=10M, bei der heutigen Geschwindigkeit moderner Datenträger und der relativ geringen Größe von typischen ISO-Images mit Linux-Live-ISOs ist der Zusatz in meinen Augen nicht nötig.

ISO-Image mit Gnome-Disk-Tool schreiben

Dass man aber auch mit dem Gnome-Disks-Tool (kurz Disks oder in der Aktivitäten-Übersicht auch Laufwerke genannt) ebenfalls ISO-Images auf USB-Sticks schreiben kann, habe ich erst vor Kurzem bemerkt. Neben ein paar Komfort-Features wie einer Fortschrittsanzeige und Hinweisen, dass der USB-Stick zu groß oder zu klein sein könnte, macht das Gnome-Disks Tools das Heraussuchen des Speicherorts natürlich noch leichter. Der angeschlossene USB-Stick ist in Disks nicht zu übersehen, so sollte das Risiko etwas zu verbasteln eigentlich minimiert werden.

Auch wenn meine Distro-Hopper-Zeiten vorbei sind — wenn ich es recht bedenke hatte ich eigentlich nie so eine Phase — aber dennoch muss ich recht häufig diverse ISO-Images auf einen USB-Stick oder eine Micro-SD-Speicherkarte bannen. Meine kleine Armee aus Raspberry Pis, Odroids oder Banana Pis — dazu hoffentlich in den nächsten Tagen ein wenig mehr — möchte mit Betriebssystemen versorgt werden.

Von daher wollte ich eigentlich schnell wieder Ubuntu Lucid 10.04 LTS installieren. Mit dem „Startmedienersteller“ ist ja relativ schnell ein USB-Stick mit Lucid erstellt. Doch beim Booten des Rechners empfängt mich nur noch dieser nette Screen…

SYSLINUX 4.01 debian-20100714 EDD Copyright (C) 1994-2010 H. Peter Anvin et al
Unknown keyword in configuration file: gfxboot
boot:
vesamenu.c32: not a COM32R image
boot:
vesamenu.c32: not a COM32R image
[...]

Es scheint wohl so, dass man unter Maverick keine Boot-Medien mehr mit Lucid (oder auch anderen älteren Ubuntu-Distributionen?) erstellen kann. Selbst in den Release-Notes zu Maverick wurde ein kurzer Abschnitt dazu geschrieben. Da ich gerade jedoch kein Lucid zur Hand habe, kommt mir der ein Workaround, der sich im Bug #617779 als Kommentar befindet, recht gelegen.

Wenn Ihr also unter Ubuntu Maverick einen bootbaren USB-Stick mit einer älteren Ubuntu-Version erstellen wollt und das System möchte dann später nicht booten, so gebt an diesem Boot-Prompt einfach „help“ ein und drückt danach Return. Das Live-System sollte danach brav hochfahren und Ihr könnt euer „altes“ Ubuntu installieren.

OMG!!!11EinsElf! Malware für Linux!

Mit etwas Ruhe betrachtet liegt (sitzt) das Problem dort begraben, wo langjährige Linux-Anwender es schon immer vermutet haben. Vor dem Rechner, im Abstand von ca. 50cm. Ich meine dies nicht bösartig, doch Computer sind hoch-komplexe Systeme, die viele Anwender nicht durchblicken können.

Gerade die sorglose Installation von Software aus unbekannten Quellen bricht jedem Sicherheitskonzept das Genick. Da helfen keine Personal Firewalls oder Virenscanner. Es wäre ein Leichtes ein Programm per Social-Engineering zu verteilen und es dann Daten löschen zu lassen. Dabei wäre das Betriebssystem völlig egal. Ob Windows XP, Windows 7, Mac OS X, Linux oder BSD. Egal, wird ein Programm vom Anwender ausgeführt, dann kann das Programm alles machen, was im im Kontext der Rechte des ausführenden Benutzers liegt.

Das klappt wie man im aktuellen Fall sehen kann nicht lange, dazu sind die soziale Netze der Linux-Anwender zu eng genüpft. Kaum war der Missbrauch des Pakets bekannt geworden, war es von gnome-look.org gelöscht, die Information zum Löschen der Skripte verbreitet und die herunterzuladenden Skripte auf dem Server gelöscht. Doch eine begrenzte Anzahl an „Opfern“ wird es dabei immer geben. In diesem Fall war der angerichtete Schaden minimal, doch es wäre auch andere Szenarien denkbar.

Wie kann man die Situation verbessern?

Der Hebel muss an der richtige Stelle angesetzt werden. Ein von Grund auf solide aufgebautes System braucht keinen Virenscanner oder eine Überwachung von Verzeichnissen auf Änderungen. In meinen Augen müsste man bei der Installation von Paketen aus unbekannten Quellen beginnen, den hier muss der Anwender selber die Spreu vom Weizen trennen. Dies wird ihm derzeit jedoch nicht gerade leicht gemacht.

Als Beispiel zeige ich die Installation eines .deb Paketes von RealVNC. Der Anwender sieht nur eine beliebig gestaltbare Beschreibung, Details des Paketerstellers die dieser völlig frei angeben kann und welche Datei wohin kopiert wird. Was über preinst- oder postinst-Routinen während der Installation gemacht wird ist nicht erkennbar. Eine Garantie, dass die Angaben zum Ersteller stimmen, gibt es nicht. Was könnte man besser machen?

Offizielle Zertifizierungsstellen

Es muss eindeutig erkennbar sein, von wem ein Paket stammt. Die Identifizierung darf nicht nur über ein selbst ausfüllbares Textfeld bei der Erstellung des .deb Paketes geschehen. Das Paket muss mit verifizierten Schlüsseln signiert werden. Falls der Schlüssel nicht eindeutig einer Person oder Organisation zugeordnet werden kann, dann muss die Paketverwaltung, ähnlich wie Firefox bei selbst erstellten Zertifikaten, deutlich vor dem Paket warnen.

Dafür bräuchte es Zertifizierungsstellen, die ähnlich zu CACert und Co. arbeiten. Trägt ein Paket nicht ein Zertifikat solch einer Stelle, dann muss der Anwender deutlich vor der Installation gewarnt werden. Das verhindert zwar weiterhin nicht die Installation schädlicher Pakete, doch es wird dem Anwender eine Möglichkeit an die Hand gegeben zu erkennen von wem ein Paket wirklich stammt. Allerdings kann ich jetzt schon die Aufschreie vieler Entwickler hören, die sich ihrer „Freiheit“ und ihrem Recht auf Anonymität beraubt fühlen.

Bessere Erklärung des Installationsvorganges

Die Aufzählung der bei der Installatation kopierten Dateien und ausgeführten Aktionen müsste erklärt werden. Der Anwender muss verstehen können, dass beim Kopieren von Dateien nach /etc/profile.d/ quasi ein Autostart beim Einloggen ausgeführt wird. Oder dass beim Kopieren von Dateien nach /etc/init.d/ Dienste eingerichtet werden. D.h. es müsste erklärt werden warum welche Dateien wohin kopiert werden.

So bekommen auch schlechter informierte Anwender die Chance missbräuchliche Pakete aufzudecken. Denn warum sollte etwas bei der Installation eines „neuen“ coolen Texteditors Dienste und Cron-Jobs eingerichtet werden. Dies würde die Erstellung von Paketen deutlich aufwändiger machen, doch letztendlich wäre dies ein wichtiger Schritt hin zum „aufgeklärten“ Benutzer. Denn wie schon am Anfang erklärt, die wichtigste Sicherheitsmaßnahme ist ein Benutzer, der nicht alles installiert, was ihm unter die Nase kommt.