Graphische Frontends für die Paketverwaltung gibt es zwar bei praktisch jeder großen Distribution, doch ich für meinen Teil bin mit dem Terminal einfach deutlich schneller unterwegs. Daher greife ich eigentlich immer zu apt-get und Co und nicht zum Software Center oder Synaptic. Mit Debian und seinen Sprösslingen bin ich ja „aufgewachsen“, apt-get-Befehle gehen mir daher meist flüssig von der Hand. Inzwischen klappen auch pacman und yaourt-Kommandos halbwegs schnell, ohne dass ich sie nachschlagen muss. Aber was mache ich mit yum, zypper oder emerge? Bin ich ich auf Fedora, OpenSUSE und Co. unterwegs, dann heißt es man-pages lesen oder im Netz spicken.

Wer öfters mal Abseits der gewohnten Distribution unterwegs ist, der sollte sich daher auf jeden Fall die Pacman-Rosetta-Seite aus dem Arch-Wiki als Bookmark sichern oder sie besser gleich als Spickzettel ausdrucken. Sie stellt die Befehle für pacman, yum, apt-get, zypper und emerge gegenüber und liefert auch Informationen wo die Paketverwaltungen ihre Konfigurationen ablegen oder wie man den Cache leert oder oder oder… So findet man sehr schnell den entsprechenden Befehl bei einer anderen Distribution, wenn man sich zumindest in einer Paketverwaltung halbwegs gut auskennt.

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.

Außer Spaß am Testen gibt es auch keinen Grund diese Quellen zu aktivieren. Pakete, die sich in den „proposed“-Quellen bewährt haben, wandern über kurz oder lang in die normalen Updates. Daher der dringende Aufruf: Bitte deaktiviert diese Quellen, wenn ihr keine Tester sein wollt! Ein zweiter Dorn im Auge sind mir Beiträge wie dieser von oshelpdesk.org. Dort findet man aktuell eine sage und schreibe 353-zeilige Liste als „Ergänzung“ für die eigene /etc/apt/sources.list der Paketverwaltung. Diese Listen sind böse und bringen Baby-Tux zum Weinen!

Solch eine irrsinnige Sammlungen an planlos zusammen gesammelten Paketquellen führt dahin, dass ihr euer System mit Sicherheit nicht von Einer zur nächsten Ubuntu Version upgraden könnt. Noch viel gravierender wiegt jedoch die Tatsache, dass beliebige Teile des Systems durch einer Paketquelle ausgetauscht werden könnten. Dazu hatte ich schon einmal eine kleine Geschichte über fremde Paketquellen verfasst. Im Wiki von ubuntuusers.de warnen wir auch alle Nase lang vor fremden Paketquellen… Per se sind sie nicht böse, wenn man solch Quellen bewusst und gezielt einsetzt. Doch so planlos eingesetzt, sind sie ein gravierendes Problem. Mir dreht es den Magen um! Also bitte liebe User, nicht nachmachen…