März 2014

Hier finden Sie Nachrichten und Einträge aus dem März 2014, die sich einmal als News direkt auf der Homepage befunden haben.

19. März 2014: Vor mehr als 5 Jahren habe ich bei Fedora einen Bugreport gegen NetworkManager-openvpn geöffnet, da die von OpenVPN unterstützte abweichende "keysize"-Option nicht in NetworkManager-openvpn vorhanden ist. Das bedeutet, dass die OpenVPN-Integration im NetworkManager nicht mit einer gehärteten OpenVPN-Serverkonfiguration verwendet werden kann. Der Feature-Request wurde damals zurückgewiesen und der Bugreport somit geschlossen. Vor etwas mehr als einem halben Jahr hat Steve Warren einen Bugreport beim GNOME-Projekt mit der gleichen Problematik geöffnet und Jiří Klimeš hat einen Patch entwickelt welcher in den NetworkManager 0.9.x eingeflossen ist. Leider wurde dieser Patch nie für den älteren NetworkManager 0.8.x zurückportiert - der beispielsweise noch von Red Hat Enterprise Linux 6 eingesetzt wird. Genau das habe ich gestern Abend bzw. heute früh gemacht - neben kleineren Anpassungen des C-Codes waren die Anpassungen in der GUI rund um bzw. mit Glade die größte Herausforderung. Das Ergebnis ist ein Patch welcher in ein Update von NetworkManager-openvpn für Fedora EPEL eingeflossen ist!

20. März 2014: Nach meinem Vortrag "SELinux: Bitte nicht deaktivieren …" auf den Chemnitzer Linux-Tagen kam ein Zuhörer auf mich zu und hat mich auf ein Problem in der SELinux-Richtlinie von Red Hat Enterprise Linux 6 aufmerksam gemacht: Die SSH-Anmeldung per SSO auf einem Server dauert sehr lange wenn der Schreibzugriff auf /dev/urandom von SELinux verboten wird. Da SSO über Kerberos gelöst wird habe ich das Problem in diesem Zusammenhang vermutet und einen Bugreport im Red Hat Bugzilla geöffnet. Im weiteren Verlauf hat sich herausgestellt, dass statt dem standardmäßig von RHEL mitgelieferten MIT Kerberos ein Heimdal Kerberos zum Einsatz kommt. Dieses versucht die Entropie mit Seeding durch Schreiben auf /dev/urandom zu erhöhen - was wohl unter Linux keinen Sinn ergibt. Daraufhin habe ich kurzerhand die Heimdal-Entwickler kontaktiert und Love Hörnquist Åstrand hat einen Patch geschrieben der in zukünftigen Versionen von Heimdal Kerberos enthalten sein wird. Damit handelt es sich nicht um einen Fehler in der SELinux-Richtlinie sondern um einen normalen Software-Fehler der mit SELinux identifiziert werden konnte...

21. März 2014: Nachdem ich in dieser Woche mal wieder über die Einrichtung von Parallelport-Karten, die nicht automatisch erkannt werden, gestolpert bin, habe ich mich diesmal entschieden einen kleinen Artikel zu schreiben. Die Anleitung ist jedoch weniger für mich selbst gedacht als vielmehr für diejenigen, die mich von Zeit zu Zeit danach fragen. Zwar ist die Einrichtung von Parallelport-Karten auch in den Quellen des Linux-Kernels recht gut dokumentiert, doch scheinen diese Hinweise in der Praxis wohl nicht eindeutig oder einfach genug zu sein. Möglicherweise hängt es auch mit dem Fehlen eines konkreten und etwas komplizierteren Beispiels zusammen, das sich in meiner Anleitung hingegen findet.

22. März 2014: Es ist nun etwas mehr als zwei Jahre her seit er gestorben ist. Sein Grab hat sich zwar bislang recht wenig gesetzt, aber das wird sich in absehbarer Zeit vermutlich auch recht wenig ändern. Heute haben wir uns auf die Suche nach einem Grabmal, einem Grabstein, gemacht. Ob man es als Vorteil bezeichnen kann, dass wir vor etwas mehr als vier Jahren auf der Suche nach einem Grabstein für sie waren, weiß ich nicht so wirklich. Jedenfalls hat es die Suche einfacher gestaltet, da wir bereits eine Vorstellung zu Form und Material des Steins sowie zur Art und Farbe der Schrift hatten. Da wir bereits bei ihrem Grabstein insgesamt sehr gute Erfahrungen mit der Michael Freihofer GmbH gemacht hatten, haben wir uns für einen erneuten Besuch dort entschieden. Vermutlich wird es bei ihm ein ähnlicher Grabstein wie bei ihr werden...

23. März 2014: Als ich heute Nacht die Auswertungen meiner Webseiten bei den Google Webmaster Tools angesehen habe, habe ich nicht widerstehen können und kurzerhand das Sitemaps-Protokoll in meine Webseiten eingebaut. Im Unterschied zu vielen anderen Webseiten setze ich kein fertiges Content-Management-System (CMS) ein, sondern eine Eigenentwicklung - welche ich jedoch nicht direkt als klassisches CMS bezeichnen würde. Letztendlich ist es eine äußerst performante Sammlung an PHP-Skripten bzw. -Funktionen, die zwischen die eigentlichen Inhalten eingefügt werden. Das mag sich ein bisschen nach SSI anhören, hat aber die Mächtigkeit von PHP. Die Möglichkeit Meta-Informationen zu hinterlegen kommt mir damit beim Sitemap-Protokoll zugute. Letztendlich wird die Sitemap nun von einem PHP-Skript erzeugt welches die eigentlichen Seiten der Webseite ermittelt und jeweils die relevanten Meta-Informationen zur Sichtbarkeit auswertet. Im gleichen Zuge habe ich mich entschieden einige meiner "robots.txt"-Dateien basierend auf dem Robots Exclusion Standard absofort automatisch generieren zu lassen.

24. März 2014: Bei Datenschützern und Fachanwälten dürfte das Urteil des Landgerichts Frankfurt am Main vom 18.02.2014 (Az. 3-10 O 86-12) vermutlich für Erstaunen gesorgt haben; Volltextveröffentlichungen sind auf dejure.org verlinkt. Soweit ich das als Nichtjurist verstehe kritisiert das Gericht den Einsatz von Piwik auf dem eigenen Webserver (selbst wenn die Anonymisierung aktiviert ist) sofern der Besucher der Webseite nicht explizit auf das "anonyme Tracking" durch Piwik hingewiesen wird. Das ist interessant und erschreckend zugleich, denn meines Verständnisses als Nichtdatenschützer nach hält es der Landesdatenschutzbeauftragte für ausreichend entsprechende Anonymisierungsfunktionen in z.B. Google Analytics und Piwik zu aktivieren. Aus rein technischer Sicht sind die ganzen Anonymisierungsfunktionen in den Webtracking-Tools sowieso nur rechtliche Augenwischerei: Beim Laden eines in die Webseite eingebundenen Webtracking-Tools wird immer die IP-Adresse des Besuchers an das Webtracking-Tool übermittelt - vollständig und nicht anonymisiert. Dies liegt schlichtweg an dem darunterliegenden TCP/IP. Ein Schelm, wer Böses dabei denkt! Meines Erachtens ist es naiv zu glauben, dass irgendein Webtracking-Dienst lediglich die anonymisierte IP-Adresse verwendet, wenn dieser mit einer HTTP-Anfrage gleichzeitig auch die nicht anonymisierte IP-Adresse erhält...

25. März 2014: Beim gestrigen Besuch der Webseite des "Landesbeauftragten für den Datenschutz in Baden-Württemberg" ist mir etwas aufgefallen: Die Webseite unterstützt gar keine verschlüsselte Verbindungen (HTTPS). Der Port 443 (TCP) ist zwar geöffnet doch antwortet dort nur ein Webserver im Klartext. Mein nächster Blick fiel auf den Mailserver "mail1.bwl.de" der - abgesehen von fehlender IPv6-Unterstützung - immerhin STARTTLS anbietet. Eine Zertifikatskette sucht man vergebens. Abgesehen davon ist das verwendete SSL/TLS-Zertifikat laut OU ein SGC-Zertifikat welches generell vermutlich mehr Sicherheitsbedenken verursacht als es löst. Schaut man sich das SSL/TLS-Zertifikat weiter an, so stellt man fest, dass dieses von der "Comodo High-Assurance Secure Server CA" ausgestellt bzw. signiert wurde. Danach sticht ins Auge, dass der Mailserver zwar TLSv1.0, nicht aber TLSv1.2 unterstützt - nach TR-02102-2 (Version 2014-01) des BSI noch unter bestimmten Umständen akzeptabel. Der Verschlüsselungsalgorithmus RC4 sollte laut gleichem Dokument nicht mehr eingesetzt werden, aber "mail1.bwl.de" lässt "RC4-MD5" und "DES-CBC-SHA" zu. Eine deutsche CA, DNSSEC und DANE? Fehlanzeige! Sollte ein Landesdatenschutzbeauftragter nicht mit gutem Beispiel vorangehen? Herr Landesdatenschutzbeauftragter, laden Sie mich doch bitte mal zu einem Kaffee bei Ihnen ein...

26. März 2014: Heute habe ich mir die Webseite der "Bundesbeauftragten für den Datenschutz und die Informationsfreiheit" vorgenommen: Diese unterstützt (optional) HTTPS-Verbindungen mit wenigstens SSLv3 bis hin zu TLSv1.2. Bei den Verschlüsselungsalgorithmen ist sogar ECC gegeben - allerdings findet sich leider auch RC4 (das nicht mehr verwendet werden sollte) am Ende der Cipher Suite. Das SSL/TLS-Zertifikat wurde von der deutschen CA "TC TrustCenter GmbH" ausgestellt, die inzwischen ein Teil von Symantec geworden ist. Bei den beiden Mailservern, "mx1.bund.de" und "mx2.bund.de" sieht es dafür schlechter aus: IPv6-Unterstützung sucht man sowieso vergebens, STARTTLS wird zwar angeboten, doch nur mit einem "selbstsignierten" SSL/TLS-Zertifikat der Zertifizierungsstelle des BSI. Im besten Falle wird die Verbindung mit TLSv1.0 verschlüsselt aber man kann die Transportverschlüsselung leider auch auf das völlig unsichere SSLv2 mit den Verschlüsselungsalgorithmen "DES-CBC3-MD5", "RC2-CBC-MD5" oder "RC4-MD5" herabsetzen...obwohl TR-02102-2 (Version 2014-01) des BSI den Einsatz von SSLv2 in Abschnitt 3.2 nicht mehr zulässt. Wow, DNSSEC ist sogar vorhanden, DANE nicht. Sollte eine Bundesdatenschutzbeauftragte nicht mit gutem Beispiel vorangehen? Frau Bundesdatenschutzbeauftragte, laden Sie mich doch bitte mal zu einem Kaffee bei Ihnen ein...

29. März 2014: Meinen heutigen Abend habe ich mit dem Schreiben von zwei neuen längeren Artikeln verbracht. Der erste Artikel dreht sich um die Migration eines bestehenden Systems mit Red Hat Enterprise Linux von der bisherigen Systemmanagement-Plattform Red Hat Network zum neuen Red Hat Subscription Manager. Dabei sind meine ganzen Erfahrungen und Probleme eingeflossen, die ich bei der Benutzung seit dem Frühjahr 2012 mit RHSM gemacht habe - natürlich auch meine Workarounds sowie Verweise auf die geöffneten Bugreports. Mein zweiter Artikel dreht sich um die Vergrößerung einer bestehenden Partition unter Linux - ohne grafische Hilfsmittel. Nachdem ich in der vergangenen Woche über diese Thematik gestolpert bin und feststellen musste, dass (vermutlich aufgrund von LVM) die klassische Partitionierung scheinbar eine Herausforderung geworden ist, versuche ich dem nun ein bisschen entgegenzuwirken.

31. März 2014: In die heute veröffentlichte Version 7.1.9 der Zarafa Collaboration Platform (ZCP) ist auch ein von mir entwickelter Patch eingeflossen. Dieser fügt den STLS-Befehl (STARTTLS) gemäß RFC 2595 dem POP3-Dienst des Zarafa-Gateways hinzu. Damit ist es erstmals im Zarafa-Gateway überhaupt möglich eine verschlüsselte Verbindung über den Port 110 (TCP) zu nutzen. Bisher konnte dafür ausschließlich der inzwischen überholte Port 995 (TCP) für POP3S verwendet werden. Der Steuerbefehl "STLS" sorgt letztendlich für die Einleitung einer verschlüsselten Verbindung und führt damit zum "Upgrade" einer bestehenden Klartext-Verbindung - wie sie bei POP3 normalerweise der Fall ist. Einen unschönen Makel hat Zarafa 7.1.9 allerdings bereits: Die Sicherheitslücken CVE-2014-0079 (für die ich sogar einen Patch bereitgestellt habe) und die neuere Lücke CVE-2014-0103 (Passwörter des Zarafa WebAccess und der Zarafa WebApp werden im Klartext in der PHP-Session abgelegt) existieren leider weiterhin und wurden somit nicht geschlossen.