Zeichensatzvorgaben für MySQL und PHP – SET NAMES – und leere Strings durch htmlentities()

Gestern ist mir ein dummer Fehler passiert, dessen Analyse mich Zeit gekostet hat. Dabei erwies sich die Sache am Ende als trivial. Es ging letztlich um konsistente Zeichensatzeinstellungen für PHP und MySQL - allerdings mit einem mir bislang unbekannten Nebeneffekt.

Zeichensätze im Kontext von PHP und MySQL sind ein Thema vieler Foren- und Q&A-Artikel im Internet - und nicht immer trifft man auf zufriedenstellende Antworten. Ich hoffe, dieser Artikel trägt anhand eines Beispiels zu etwas mehr Klarheit bei.

Voraussetzungen und aufgetretener Fehler

Unsere hausinternen Apache- und Datenbank-Server laufen normalerweise vollständig unter UTF-8. Inklusive der eigenen Datenbank- und Tabellen-Kollationen unter MySQL- oder MariaDB-Systemen. Aber für Tests müssen wir immer mal wieder gezielt eine Kompatibilität zu den festgelegten Kollationen für MySQL-Banken/Tabellen auf Kundenservern herstellen. Meist kommt dann Latin1 (iso-8859-1) ins Spiel.

Gestern mussten wir für einen solchen Test Datensätze eines von uns entwickelten, php-basierten CMS von einem gehosteten MySQL-Kundenserver in unsere lokale Test-Datenbank übernehmen. Diese Datensätze beinhalteten viele Text-Strings mit deutschen Umlauten. Da es sich nur um wenige Records handelte, haben wir die Daten in diesem Fall mit Copy/Paste und mit Hilfe von Eingabefeldern unserer CMS-Verwaltungsoberfläche übernommen. Das CMS lief dabei unter einer lokalen UTF8-Standarddomäne. Unsere aktuellen CMS-Programme zeigten die fraglichen Textstrings denn auch korrekt in der Web-Oberfläche des CMS an.

Es gab aber andere zu untersuchende Punkte im Layout. Um die Unstimmigkeiten zu testen, haben wir zusätzlich eine separate Testdomäne angelegt und diverse PHP-Klassen vom Kundenserver (auf dem dortigen Versionsstand) in bestimmte Verzeichnisse des zugehörigen Web-Spaces auf unserem lokalen Server geladen. Ergebnis: 2 Domainen mit z.T. unterschiedlichen Versionsständen von PHP-Klassen.

Und dann passierte es:

Bei einem Aufruf der Webseiten in der Testdomäne verschwanden plötzlich fast alle Text-Strings aus der Web-Oberfläche.

Bilder und grundsätzlicher Aufbau der Webseiten bleiben jedoch erhalten. Ich war zunächst völlig verblüfft über diesen Effekt. Zumal der Einsatz unserer lokalen Versionen der gleichen PHP-Klassen kein Verschwinden der Textstrings zeitigte.

Die Analyse war nicht ohne, da ich zunächst nicht wusste, wonach ich zu suchen hatte. Man denkt da zunächst natürlich an Unterschiede im Programmcode selbst. Am Schluss entpuppten sich aber eine im wesentlichen unmodifizierte Klasse, die die Datenbankverbindung steuert, sowie eine Klasse, die die Strings aus Sicherheitsgründen nach unerlaubten Sequenzen filtert, als Kerne des Übels. Ausschlaggebend waren allerdings nicht Programmunterschiede sondern bestimmte Parameter-Setzungen sowie Server- und Zeichensatzeinstellungen. Aber der Reihe nach.

Zeichensatzeinstellungen in der Kommunikationskette zwischen einem PHP-Server und einer MySQL-Datenbank

In der Datenaustausch-Kette zwischen einer MySQL-Datenbank und PHP-Modulen auf einem Web-Server (und natürlich auch bei der Übersendung eines HTML-/XML- oder JSON-Outputs an Web-Clients) spielen verschiedene Zeichensatzeinstellungen eine Rolle. Einige davon können vom Entwickler beeinflusst werden. Andere wiederum nicht immer.

Für unseren Fall waren vor allem die nachfolgenden Punkte relevant; sie betreffen den Web-Server (mit PHP-Modul) und die MySQL-Datenbank:

  1. Zeichensätze ("Kollationen") der MySQL-Datenbank und zugehöriger Datenbanktabellen.
  2. Zeichensatz-Vorgaben zur MySQL-Verbindung und zum Datentransfer von und zu (PHP-)Programmen, die mittels der SQL-Direktive "SET NAMES" vorgenommen wurden.
  3. Einstellungen für den Default-Character-Set des PHP-Apache-Moduls.
  4. Zeichensatzeinstellungen für die PHP-Funktion "htmlentities()".

Zeichensätze in der Datenbank und die Direktive "SET NAMES"

Für die Kollation der relevanten MySQL-Datenbank und ihrer Tabellen war auf dem Kundenserver "latin1_german2_ci" gewählt worden. Unsere Einstellungen im lokalen Testsystem waren dazu auf Tabellenebene kompatibel. Die Kollation einer Datenbanktabelle bestimmt letztlich aber nur die interne Ablage der Daten in der Tabelle und nicht den Zeichensatz, unter dem z.B. per SQL ermittelte Resultsets an weiterverarbeitende Programme übermittelt werden.

Für letzteres sind andere Parameter verantwortlich, die man als Entwickler für eine spezifische Verbindung zur MySQL-Datenbank einstellen kann. Unter MySQL und der MariaDB nutzt man dafür etwa die SQL-Direktive "SET NAMES" (oder aber die Funktion mysqli_set_charset(); s.u.).

"SET NAMES" führt zur gleichzeitigen Festlegung dreier RDBMS-Parameter für die Behandlung einer spezifischen Datenbankverbindung. Diese Parameter sind: character_set_client, character_set_connection, character_set_results.

Siehe hierzu etwa
https://dev.mysql.com/doc/refman/5.7/en/set-names.html
und
https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_character_set_results.

Die Datenbankverbindung wird unter dem PHP/mysqli-Interface dabei über das Connection-Objekt

$dbi = mysqli_connect(....)

identifiziert. Im Wesentlichen legen die genannten Parameter Folgendes fest:

  • character_set_client: Zeichensatz, unter dem Daten, die vom Datenbank-Client zum RDBMS-Server transferiert werden, interpretiert werden.
  • character_set_connection: Handhabung bestimmterErsetzungen und Konversionen, u.a. von Numbers zu Strings.
  • character_set_results: Zeichensatz, unter dem Daten, die vom RDBMS zu Client-Programmen übermittelt werden interpretiert werden.

Der "Client" ist in unserem Fall natürlich ein PHP-Programm auf einem Apache-Server. Die Anwendung des "SET NAMES"-Statements durch ein PHP-Programm, z.B.

$sql_unames = "SET NAMES 'utf8'";
$this->dbi->query($sql_unames);
//dbi->Datenbank-Connection Object
//$this->dbi = mysqli_connect(....)

ist somit von zentraler Bedeutung für die Kommunikation zwischen einem PHP-Programm und einer MySQL/MariaDB! Solange eine hinreichende Konvertierung verwendeter Zeichen gewährleistet ist, muss der Zeichensatz, unter dem Resultsets zum PHP-Programm übermittelt werden, nicht zwingend mit dem der Datenbanktabellen selbst identisch sein.

Es sei darauf hingewiesen, dass es zu "SET NAMES" auch Alternativen gibt, die man im Rahmen des mysqli-Interfaces einsetzen kann und sollte (s.u.). Dass wir in einigen Programmen noch SET NAMES verwenden, hat lediglich historische Gründe. Die hier beschriebene Problematik gilt aber unabhängig vom genauen Werkzeug zur Einstellung der Zeichensatzparameter.

Konsistenz zu Zeichensatzvorgaben für PHP - Einstellungen in der php.ini

Das PHP-Programm muss in jedem Fall mit dem gewählten Zeichensatz für Resultsets adäquat umgehen können; s.u.. Der rechte Bereich der folgenden Skizze, die ich aus einem anderen Artikel dieses Blogs entliehen habe, verdeutlicht das für den Fall "SET NAMES 'latin1'" :

Nun könnte man in seinen PHP-Programmen natürlich spezifische Umwandlungsfunktionen (u.a. iconv(), mb_convert_encoding(), utf8-encode(), utf8-decode) für die Zeichensatzkonvertierung aus- und eingehender Strings bemühen. Die linke Seite der Skizze liefert hierfür Beispiele (s. den dazu gehörigen Abschnitt weiter unten).

Wenn möglich, kann man aber auch einen Standardzeichensatz für die PHP-Verarbeitung von Strings vorgeben und sich darauf bzgl. der Datenbankinteraktion verlassen.

Entsprechende Einstellungen nimmt man in der Konfigurationsdatei
/etc/php7/apache2/php.ini
vor. Die relevanten Parameter sind dort:

; PHP's default character set is set to UTF-8.
; http://php.net/default-charset
default_charset = "UTF-8"

; PHP internal character encoding is set to empty.
; If empty, default_charset is used.
; http://php.net/internal-encoding
;internal_encoding =

; PHP input character encoding is set to empty.
; If empty, default_charset is used.
; http://php.net/input-encoding
;input_encoding =

; PHP output character encoding is set to empty.
; If empty, default_charset is used.
; mbstring or iconv output handler is used.
; See also output_buffer.
; http://php.net/output-encoding
;output_encoding =

Die hierfür gesetzten Werten sollte natürlich mit den Einstellungen für die Datenbankverbindung zusammenpassen.

Kundenvorgaben

Wir parametrieren in Kundenprojekten die PHP-Methoden für den Verbindungsaufbau zum Datenbankserver meist gemäß expliziter Kundenvorgaben. In unserem Fall hatten wir "SET NAMES 'latin1'" gewählt. (Hinweis: Die Zeichensatz-Namen auf einem MySQL-Server enthalten grundsätzlich keine Trennzeichen; daher ist statt iso8859-1 "latin1" zu verwenden).

Der Grund dafür war, dass das Apache-PHP-Modul des (gehosteten) Kunden-Web-Servers auf "iso-8859-1" eingestellt war. Das bestätigte eine Überprüfung mit phpinfo(). Diese Einstellungen sollten wir gem. Kundenvorgabe nicht ändern, da auf dem Web-Server auch andere PHP-Programme als unsere eigenen laufen müssen.

Auf dem Kundenserver waren die Zeichensatzeinstellungen also konsistent.

Ursache unseres Problems und die Rolle von htmlentities()

Man ahnt es bereits: Durch das Kopieren der PHP-Klasse für die Steuerung von Datenbankverbindungen vom Kundenserver auf die Testdomäne unseres lokalen Web-Servers entstand dort u.a. eine Inkonsistenz zwischen der Zeichensatzbehandlung unter PHP (utf8!) und dem Zeichensatz für den Transfer von Resultsets aus der MySQL-Datenbank (latin1).

Diese Inkonsistenz kam jedoch noch nicht zum Tragen, als wir die Daten per Copy/Paste über lokale Web-Interfaces einer UTF8-Standard-Domäne in die Bank einbrachten.

Für unsere Testdomäne dagegen muss man jedoch u.a. eine fehlerhafte Konvertierung von deutschen Umlauten erwarten! Warum aber verschwanden die Text-Strings in Gänze aus den Web-Oberflächen?

Die Antwort lieferte schließlich eine von mir bislang zu wenig beachtete Eigenschaft der PHP-Funktion "htmlentities()".

Unsere Web-Generatoren jagen Strings vor einer Web-Darstellung durch eine Reihe von Prüfroutinen, Transformatoren für erlaubte Zeichenfolgen und durch Filter (u.a. HTMLPurifier, aber auch eigene Filter). Dabei wird in einem Zwischenschritt (nach einer vorhergehenden Konvertierung erlaubter HTML-Zeichenfolgen) auch "htmlentities()" eingesetzt.

htmlentities() erlaubt selbst eine Vorgabe des "Character Sets" über einen Parameter. Ein Check zeigte: Dieser Parameter stand in der lokalen Testdomäne explizit auf "UTF-8". Diese Einstellung betrifft jedoch eine Konvertierung in den gewünschten Ziel-Zeichensatz für den HTML-Output. Hier hatten wir kein Problem, da die HTML-Header der Webseiten bzw. die vom Apache-Server generierten HTTP-Header tatsächlich auf UTF-8 ausgerichtet waren.

Allerdings sorgten schon die vorhergehenden Widersprüche zwischen dem Zeichensatz der Datenbank-Resultsets und dem Zeichensatz für die anschließende Behandlung von Strings durch PHP. Das hatte gravierende Folgen. Unter http://php.net/manual/de/function.htmlentities.php findet man nämlich folgenden Hinweis:

Rückgabewerte
Gibt die kodierte Zeichenkette zurück. Enthält der string eine in dem übergebenen encoding ungültige Code Unit Sequenz, wird eine leere Zeichenkette zurückgegeben, sofern weder das ENT_IGNORE noch das ENT_SUBSITUTE Flag gesetzt sind.

(Hervorhebung durch mich).

Das war des Rätsels Lösung:

Eine Inkonsistenz in der Zeichensatzbehandlung im Datenaustausch zwischen unserer MySQL-Datenbank und PHP führte zu nicht behandelbaren Zeichen bei der Anwendung von htmlentities() auf Strings - und diese Funktion produzierte dann gemäß ihrer Default-Einstellungen leere Strings.

Trivial - man muss es halt nur wissen! Ein Test mit

"SET NAMES 'utf8'"

ließ denn alle verschwundenen Strings auch in unserer Testdomäne prompt wieder erscheinen!

Notwendige Checks vor der Anwendung von SET NAMES (oder von mysqli_set_charset())

Hat man die Kette der Zeichensatzsetzungen bzw. Zeichensatzbehandlung im Austausch zwischen PHP und einer MySQL-Datenbank erst einmal verstanden, so ist auch klar, wo man mit vorbeugenden Maßnahmen ansetzen kann. Solche Vorkehrungen sind - wie das Beispiel zeigt - vor allem dann notwendig, wenn man die Zeichensatz-Einstellungen für PHP nicht auf allen involvierten Web-Servern beeinflussen kann oder darf.

Bevor man "SET NAMES" (oder mysqli_set_charset(); s.u.) in einem PHP-Programm tatsächlich anwendet, sollte man die Setzung des "Default Character Sets" in der php.ini für den aktuellen Server explizit abfragen - mittels

ini_get('default_charset');

- und dann mit der ebenfalls abfragbaren Kollation der Datenbanktabellen vergleichen. Das Ergebnis dieses Vergleichs kann man dann nach bestimmten Regeln behandeln:

Z.B. Warnhinweise bei (ernsthafter) Inkompatibilität ausgeben. Oder wenn man wirklich sicher ist, dass nur deutsche Umlaute zu potentiellen Problemen führen können: Wahl des zu den PHP-Einstellungen konsistenten Zeichensatzes für den Transfer von Resultsets aus der Datenbank. In unserem Fall also "utf8".

Alternative: Ändern der php.ini-Vorgaben für den Zeichensatz durch und für das laufende PHP-Programm

Auf festgestellte Inkonsistenzen in den Zeichensatzeinstellungen kann man u.U. - nämlich wenn man die dafür nötigen Rechte besitzt - auch mit einer Modifikation der php.ini-Vorgaben für das laufende Programm reagieren. Dazu muss man natürlich die Funktion ini_set() bemühen; Bsp.:

ini_set( string 'default_charset', 'ISO-8859-1')

bemühen.

Empfohlener Weg zum Setzen des "Character Sets" für eine MySQL-Verbindung

Ich möchte explizit darauf hinweisen, dass es andere Möglichkeiten als die SQL-Direktive "SET NAMES" gibt, Character Sets für die Datenbankverbindung zu setzen. Das PHP-Manual empfiehlt explizit, die Funktion

mysqli_set_charset(mysqli $link , string $charset)

anstelle von SQL und "Set Names" zu verwenden. Siehe: http://php.net/manual/de/mysqli.set-charset.php

Zeichensätze und die Web-Client-Seite

Obwohl nicht Kernthema dieses Artikels werfen wir noch einen ergänzenden Blick auf den Datenaustausch des PHP/Web-Servers mit Web-Clients (z.B. einem Browser). Die Zeichensatzthematik setzt sich natürlich auch auf dieser Kommunikationsstrecke fort; der linke Teil der obigen Skizze verdeutlicht das am Beispiel von Ajax/Ajaj-Programmen. Diese erfordern i.d.R. UTF-8 für einen ordnungsgemäßen Datenaustausch mit dem Web-Server.

Ist der Parameter "default_charset" in der php.ini-Datei aber auf "iso-8859-1" gesetzt, so muss man ein- und ausgehende Daten entsprechend konvertieren. Dafür eignen sich die Funktionen utf8_decode() für einlaufende POST-/GET-Daten aus Ajax-Programmen und utf8_encode() bei der Erzeugung des Ajax/Ajaj-Outputs in Richtung Web-Client.

Für reinen HTML-Output gilt analoges; dabei sind aber auch HTTP- und HTML-Header-Anweisungen für Character Sets zu setzen. Siehe hierzu:
http://www.html-info.eu/php/php-als-script-sprache/item/zeichensatz-latin1-oder-unicode-utf-8.html

Fazit

In unbeabsichtigter Weise kann htmlentities() plötzlich zu einer Testfunktion für die Konsistenz zwischen

  • der Zeichensatz-Einstellungen durch "SET NAMES" bzw. mysqli_set_charset() für die MySQL/MariaDB-Datenbankanbindung an ein PHP-Programm
  • und den Zeichensatzeinstellungen für das PHP-Modul selbst auf dem Webserver

werden - und in letzter Konsequenz zu leeren Strings auf Webseiten führen.

Es lohnt sich vor einem Einsatz von "SET NAMES" - oder besser mysqli_set_charset() - eigentlich immer, die Einstellungen in der "php.ini" bzgl. des "default_charset" und verwandter Parameter abzufragen und daraus angemessene Konsequenzen für den Aufbau der Datenbankverbindung zu ziehen.

Dies gilt vor allem dann, wenn man im Rahmen von Tests und Produktivierungen auf verschiedenen Servern arbeiten will oder muss - und dabei nicht alle Konfigurationsparameter der Server selbst beeinflussen kann und darf.

Neben dem Setzen von Server- und Verbindungsparametern kann man auf festgestellte oder vorgegebene Zeichensatzanforderungen oder Zeichensatzdiskrepanzen aber auch gezielt mit verschiedenen Funktionen reagieren, die PHP für eine Zeichensatz-Detektion und eine explizite Zeichensatzkonvertierung von Strings anbietet.

Veracrypt, SSHFS und sichere Datenhaltung auf gehosteten Servern – II – die Client-Seite …

Vor einigen Tagen habe ich abends ein paar begeisterte Linux-Anhänger getroffen; einige Gesprächspartner haben mir gegenüber die Sicherheit von Linux gegenüber MS Windows hervorhoben. Bei allem Respekt: IT-Sicherheit ist selten nur eine Frage des Betriebssystems. Wer meint, dass die Installation von Linux "Sicherheit" quasi garantieren würde, irrt gewaltig. Der Einsatz von Linux entbindet den Nutzer keineswegs

  • von einer detaillierten Risiko-Analyse/-Bewertung für potentiell bedrohte Daten oder Systeme
  • und von der Festlegung geeigneter Gegenmaßnahmen.

Dieser Artikel liefert hierfür ein relativ einfaches Beispiel:

Wir betrachten die Sicherheit der Inhalte von Dateien, die wir in verschlüsselten Datei-Containern verwahren. Wir öffnen solche Dateien bei Bedarf beispielsweise auf einem Laptop. Der Kontext wurde durch den vorhergehenden Artikel dieser Miniserie

Veracrypt, SSHFS und kryptierte Datenhaltung auf gehosteten Servern – I

vorgegeben: Dort hatte ich beschrieben, wie man verschlüsselte Veracrypt-Container auf gehosteten Servern zur Lagerung geheimzuhaltender Informationen einsetzen kann. Ich hatte bereits im letzten Artikel betont, dass die Dateien auf dem Server selbst nie in entschlüsselter Form verwendet werden sollten. Um diesen Punkt herum rankten sich dann zwei durchzuführende Mount-Prozesse, um die Container-Inhalte remote auf einem Client - z.B. auf einem mobilen Laptop - bequem nutzen zu können.

Der Client ist also das System, auf dem wir unsere geheimen Daten entschlüsseln und konkret nutzen. Ich gehe nachfolgend auf einige ausgewählte und prinzipielle Sicherheitsaspekte ein, die man dort im Auge behalten sollte. Die Liste der sicherheitsrelevanten Punkte ist damit keineswegs abgedeckt; aber unsere Diskussion wird zeigen, dass Sicherheit immer nur durch eine Kombination verschiedener Maßnahmen entsteht - unter Linux ebenso wie unter anderen Betriebssystemen. Linux erleichtert dem User dabei im Idealfall die Umsetzung der notwendigen Maßnahmen; der Einsatz von Linux allein ist für die Erfüllung von Geheimhaltungspflichten in der Regel aber unzureichend.

Ausgangssituation und Nutzerverhalten

Die zu schützenden Güter (im ISO 27001-Jargon: Assets) sind in unserem Beispiel geheimzuhaltende Informationen, welche in Dateiform vorliegen. Nehmen wir als extremes Beispiel etwa eine "odt"-Datei, in der der User etliche schwer zu merkende Passwörter hinterlegt hinterlegt hat. Ein ebenso brisantes Beispiel wäre etwa die Hinterlegung von Patientendaten, auf die eine Ärztin im mobilen Einsatz zugreifen möchte, in einem verschlüsselten Dateicontainer. Der Container kann remote vorliegen - etwa als Veracrypt-Archiv auf einem über das Internet erreichbaren Server. Verschlüsselte Container können aber auch lokal auf dem Laptop selbst angelegt sein.

Als Anwender/Anwenderin vertrauen wir dabei völlig auf die Verschlüsselung der Dateien. Unser Linux-Laptop für den mobilen Einsatz sei zeitgemäß ausgestattet und beinhalte u.a eine SSD. Als Anwender greifen wir auf unsere Dateien, wie im letzten Artikel beschrieben, bei Bedarf mit SSHFS und in jedem Fall mittels lokalet VC-Mounts auf dem Client zu.

Wenn erforderlich öffnen wir die Datei auf dem Laptop mit Hilfe einer passenden Anwendung (z.B. LibreOffice). Ggf. legen wir dort sogar eine Kopie der Datei an. Die Kopie lagern wir auf dem Laptop in einem der dortigen verschlüsselten VC-Containern. Geöffnete, entschlüsselte Dateien schließen wir nach Beendigung unserer Arbeit sofort wieder.

Als potentielles Bedrohungsszenario betrachten wir im Rahmen dieses Artikels primär den Verlust oder Diebstahl des Laptops. In diesem Fall ist ein physikalischer Zugriff Unbefugter oder Krimineller auf das Gerät möglich. Frage:

Sind unsere Dateien, die dort in einem Veracrypt-Container lagern, sicher?

Schlüsselfragen

Zunächst ist festzuhalten, dass die letzte Frage im Kern falsch gestellt. Es geht ja letztlich nicht um die Dateien, sondern um deren Inhalte. Die richtige Frage wäre: Sind die Informationen, die (u.a.) in den Dateien hinterlegt wurden, im vorgegebenen Bedrohungsszenario vor dem Zugriff Unbefugter sicher?

Ich nehme die Antwort vorweg: Nein, sie sind es nicht - zumindest nicht ohne eine Reihe von Zusatzmaßnahmen. Das liegt an einer Vielzahl von potentiellen "Schwachstellen", die sich bereits im Zuge der Entschlüsselung der Dateien auf unserem Laptop ergeben. Bereits für den Server hatten wir ja ansatzweise diskutiert, dass einmal entschlüsselte Datei-Inhalte trotz des späteren Schließens der Datei und trotz des Löschens von evtl. angelegten Kopien im Filesystem erhalten bleiben könnten. Schlüsselfragen sind also:

  • Was machen die Anwendungen, die wir zum Öffnen, Auslesen oder Bearbeiten der Dateien benutzt habe, mit den Datei-Inhalten? Wo verbleiben ggf. Reste entschlüsselter Daten nach Beendigung der Anwendung?
  • Was machen das Betriebssystem, das Desktop-System (KDE, Gnome, ...) und die eingesetzten Filesysteme mit den Dateien? Wo verbleiben ggf. Reste entschlüsselter Information?
  • Was macht unsere Hardware mit unseren Dateien? Wo verbleiben ggf. Reste entschlüsselter Information?

Wir können das nachfolgend nur schlaglichtartig beleuchten. Das ist aber schon hinreichend, um unsere Ausgangsthese zu belegen.

Anwendungen als Schwachstelle

Zur Ansicht der (durch Veracrypt) entschlüsselten Datei verwenden wir geeignete Linux-Programme (Editoren, Office-Programme, IDEs etc.). Im Beispiel etwa LibreOffice [LO]. Nun legen die meisten solcher Programme temporär oder gar dauerhaft Kopien der Datei im Originalzustand oder nach vorgenommenen Änderungen an. Das Problem ist, dass diese Kopien i.d.R. nicht im Bereich des gemounteten VC-Datei-Containers landen, sondern in anderen vordefinierten Verzeichnissen, die auch ohne gemounteten Container erreichbar sind. Dort wird die Information aber ohne weitere Maßnahmen unverschlüsselt hinterlegt!

Für LO können dies einerseits Dateien mit Recovery-Informationen (in der Regel die vollständige Datei unter "/tmp" in Ordnern/Dateien mit dem Namen "luxxxxx.." sein. Diese temporären Dateien werden nach dem regulären Schließen der Dateien zwar wieder gelöscht; im Fall eines Crashes verbleiben sie aber. Es gibt zudem auch cache-artig hinterlegte Bilder, die langfristig im /tmp-Verzeichnis verbleiben. Hat man in LO gar die Option zum automatischen Anlegen von Backup-Dateien aktiviert, so finden sich letztere dauerhaft - also auch nach dem Schließen der jeweiligen Dokumente - im vorgesehenen Ordner wieder. Bei mir etwa unter dem Standardverzeichnis "~/.config/libreoffice/4-suse/user/backup/". Natürlich unverschlüsselt!

Aber auch gezieltes Löschen und ein anschließendes Leeren des Papierkorbs nutzen nichts: Wer einmal versucht hat, gelöschte Dateien in einer Partition zu restaurieren, weiß, dass ein normales Löschen von Dateien überhaupt keine Sicherheit darstellt. Die Inhalte verbleiben lange auf den HDDs oder SSDs, bis sie wirklich überschrieben werden. Je mehr Platz (bei ext4: Inodes) ein Linux-Filesystem hat, desto größer die Wahrscheinlichkeit für ein Verbleiben der Original-Information in Festplatten-Blöcken. Die Chance, gelöschte Dateien oder Fragmente davon teilweise oder gar vollständig wiederherzustellen, ist somit relativ groß.

Aufpassen muss man natürlich auch auf Anwendungen, die mit internen oder extern Versionsverwaltungssystemen kooperieren. Solche Systeme können bei schreibenden Zugriffen u.U. eine automatische Versionierung vornehmen und eine Serie von unterschiedlichen Dateizuständen im System hinterlegen.

Identifizierte Schwachstellen:
Anwendungen erzeugen typischerweise temporäre und dauerhafte Dateikopien - in unserem Fall unverschlüsselt in Festplatten-Bereichen außerhalb des kryptierten Datei-Containers. Auch nach einem gezielten Löschen solcher Informationen lassen sich die enthaltenen Informationen von Leuten mit physikalischem Zugriff auf die Laptop-Festplatten (HDD/SSD) rekonstruieren. Zu Gegenmaßnahmen s. weiter unten.

Betriebs- und Desktop-Systeme als Schwachstelle

Bei zu geringem RAM beginnt ein Betriebssystem u.U. zu pagen bzw. zu swappen. Auch in diesem Fall landet dekryptierte Information auf der Festplatte. Ein weiteres Übel können in unserem Kontext Desktop-Suchmaschinen (z.B. unter KDE) darstellen, die ggf. automatisch Verzeichnisse, Dateien und deren Inhalte sowie geöffnete Dateien nach Schlagworten scannen. Auch dann landet unverschlüsselte Information dauerhaft auf Festplatten - nämlich in Index-Verzeichnissen oder Datenbanken der Suchmaschinen.

Identifizierte Schwachstellen:
SWAP-Bereiche auf der Platte und Datenbanken von Desktop-Suchmaschinen sind Orte für das potentielle Auffinden entschlüsselter Information.

Eraser-Programme als Gegenmaßnahme?

Wenn man seine Anwendungen sehr gut kennt und weiß, wo überall Datei-Inhalte abgelegt werden, könnte man sich gegen ein Rekonstruieren gezielt gelöschter Information ggf. dadurch absichern, dass man zu Programmen greift, die einen Löschvorgang nicht nur als Freigabe entsprechender Knoten im Filesystem verstehen sondern entsprechende Blöcke tatsächlich mit Nullen oder zufälligen Zeichen überschreiben. Dieses Vorgehen setzt, wie gesagt, voraus, dass man vollständig überblicken muss, welche Anwendungen wo genau Informationen hinterlegen. Und man muss die notwendigen Löschvorgänge auch regelmäßig durchführen.

Nun gibt es zudem Programme, die alle freigegebenen Blöcke einer Festplatte identifizieren und überschreiben können. Auch solche Programme muss man aber regelmäßig laufen lassen - u.a. vor einem Shutdown des Systems. Selbst dann besteht aber immer noch die Gefahr, dass ein Laptop in einem StandBy- oder Hybernation-Zustand verloren geht oder gestohlen wird.

Die Vorstellung, ein gezieltes Löschen und Überschreiben von freigegebenen Speicherblöcken regelmäßig und in typischen Arbeitssituationen rechtzeitig sowie ohne Lücken durchführen zu können, halte ich insgesamt für illusorisch.

Verschlüsselte Partitionen als Lösung?

Das eigentliche Fazit aus den bisherigen Überlegungen ist: Im RAM entschlüsselte und geheimzuhaltende Informationen müssen auf dem Laptop immer in verschlüsselter Form auf die Festplatten gelangen. D.h.:

Alle Partitionen auf den Speichersystemen des Clients sollten vollständig verschlüsselt betrieben werden.

Das muss unabhängig vom Einsatz von verschlüsselten Datei-Containern realisiert werden! Egal, ob letztere lokal oder remote vorliegen. Entscheidend ist, dass das Entschlüsseln und Öffnen von Container-Dateien auf dem Client in unserem Szenario immer zu einer verschlüsselten Ablage von Information auf den Datenträgern des Clients führen muss - egal was die Anwendungen oder das Betriebssystem da genau ablegen wollen.

Systeme mit verschlüsselten Partitionen kann man unter Linux z.B. mit Hilfe LUKS oder eben auch Veracrypt einrichten. Verbunden ist damit typischerweise die Eingabe eines speziellen Codes beim Hochfahren des Systems oder beim Übergang aus einem Hybernation-Zustand in den Normalbetrieb. Erst dann wird die Entschlüsselung der Partitionsinhalte vorgenommen.

Was immer eine Anwendung danach tut: Die Informationen erreichen den Plattencontroller dann nur in verschlüsselter Form (hoffentlich). Wir haben das Prinzip der verschlüsselten VC-Container, das wir bereits im letzten Artikel betrachtet hatten, inzwischen also auf die Festplatten und dortigen Partitionen des Clients ausgedehnt.

Die richtige Konsequenz aus unseren Sicherheitsanforderungen scheint also zu sein, auf den Clients nicht VC-Container für Datei-Kopien anzulegen, sondern gleich alle Platten bzw. deren Partitionen zu verschlüsseln. Nachdem wir dafür entwickelten Verfahren und Verschlüsselungsverfahren unter Linux vertrauen - sind unsere Informationen nun endlich sicher?

SSDs als Schwachstelle

Tja. Die Antwort auf die letzte Frage könnte eigentlich Ja lauten, wären da nicht sehr unangenehme Eigenschaften von modernen SSDs. Ich will hier gar nicht auf alle Details eingehen (davon verstehe ich zu wenig; s. jedoch die unten angegebenen Links). Aber der entscheidende Punkt scheint mir das Wear-Leveling zu sein, das praktisch alle modernen SSDs aufweisen. Da einzelne Speicherbausteine der SSD jederzeit ausfallen können, ist der tatsächliche Speicherplatz auf SSDs deutlich größer ausgelegt als der nutzbare Netto-Platz. Information, die auf reguläre Speicherblöcke geschrieben wird, wird redundant vervielfacht, um gegen einzelne Ausfälle von Speicherzellen gewappnet zu sein. Die Verwaltung übernimmt dabei der herstellerspezifische, in die SSD verbaute SSD-Controller in autonomer Weise. Der bemüht sich wiederum um einen gleichmäßige Auslastung aller vorhandenen Speicherzellen.

An die intern redundant hinterlegten Informationen kommt man mit Mitteln eines normalen Betriebssystems leider nicht heran. Wohl aber mit Spezialtools für das Auslesen von SSDs. Fazit:
Hast du oder hat dein System irgendwann mal unverschlüsselte Information auf die Platte geschrieben, so weißt du nicht, im welchen und wie vielen Speicherzellen diese Information auf der SSD noch vorhanden ist. Das wiederum bedeutet:

Eine SSD, die man unvorsichtigerweise irgendwann mal unverschlüsselt genutzt hat, enthält womöglich noch zu schützende Informationen in Bereichen, an die man ohne spezielle Mittel gar nicht herankommt. Wohl aber Experten, die physikalische Zugriff auf die SSD erhalten!

Nun gibt es jedoch auch Werkzeuge, die angeblich in der Lage sind, alle(!) Speicherzellen einer SSD zu überschreiben. Genau ein solches Tool müsste man bei einer SSD, die man schon benutzt hat und nun verschlüsseln will, vorab zum Einsatz bringen. Diese Tools sind aber mit Risiken verbunden, nach Auskunft mancher Tester im Internet auch nicht zuverlässig und stressen die SSD in jedem Fall.

Schlussfolgerungen

In unserem Szenario führt die bisherige Diskussion zu folgenden Punkten:

  1. Ein halbwegs sicherer Client erfordert gem. der obigen Anforderungen und Diskussion vollständig verschlüsselte Partitionen aller Festplatten und SSDs.
  2. Am besten verzichtet man auf Clients mit höchsten Sicherheitsanforderungen ganz auf den Einsatz von SSDs. Das ist übrigens die Empfehlung von Experten des BSI wie auch der Veracrypt-Entwickler.
  3. Wenn man SSDs dennoch benutzen will oder muss: An den Controller der SSD dürfen von Anfang an nur verschlüsselte Daten übermittelt werden. Die SSD ist also bereits im jungfräulichen Zustand (Fabrikzustand) ausschließlich mit verschlüsselten Partitionen zu versehen - und auch später dürfen nur verschlüsselte Partitionen hinzukommen.
  4. Zudem gibt es die Empfehlung, dass die (hinreichende lange) Passphrase oder notwendige Keyfiles für den Zugang zu den verschlüsselten Partitionen nicht geändert werden sollten. Der Grund dafür ist, dass ein sicheres Überschreiben der alten Header nicht gewährleistet werden kann. Wird also ein Password/Keyfile kompromittiert, ist es am besten eine neue SSD aufzusetzen, als auf der ursprünglichen SSD alte Passwörter zu ändern.

Ferner gilt: Wird ein Laptop im nicht heruntergefahrenen Zustand verloren/entwendet, ist diese Situation ohne weitere Maßnahmen kaum besser als bei einem unverschlüsselten System: Es ist lediglich die Sperre des Bildschirmschoners zu überwinden.

Verschlüsselte virtuelle Maschinen als Maßnahme?

Es gibt noch einen weiteren Ansatz, sich zu schützen: Nämlich virtuelle Maschinen auf verschlüsselten Partitionen oder LVM-Volumes anzulegen - und die Datei-Container vom Server nur dort zu öffnen und zu bearbeiten. Dieser Ansatz, bei dem nicht alle Partitionen des Laptops verschlüsselt werden müssten, erscheint mir halbwegs sicher; ich bin aber auch dabei ein wenig skeptisch:

  • Zum einen muss die Abschottung von Host perfekt sein. Wer überblickt das aber schon?
  • Zum anderen darf man Verzeichnisse des Gastes/Hostes nicht im jeweils anderen System nutzen oder Dateien vom Gast zum Host kopieren oder Gastdateien mit Programmen des Hosts auslesen oder öffnen. Ein Mounten von Verzeichnissen des Gastes im Host verbietet sich daher. Aber auch umgekehrt muss man aufpassen.

Die geheimzuhaltenden Dateien dürfen nur und ausschließlich im Gastsystem und mit Programmen des virtuellen Gastsystems geöffnet werden. Sie dürfen nie unter dem Host-System selbst - also hier unter dem Laptop-Betriebssystem - geöffnet werden. Also ist von Samba und NFS zum gegenseitigen Mounten von Verzeichnissen zwischen virtualisiertem Gast und Host abzusehen! Zudem dürfen sich auf den Platten des (Virtualisierungs-) Hosts keine Informationen befinden, die Hinweise auf Passwörter und die Entschlüsselung der Partitionen für den Gast geben.

Setzt man trotzdem auf den Ansatz mit virtualisierten Gastsystemen, weil man auf dem Client nicht alles verschlüsseln will, so ist es wohl am einfachsten, für das Gastsystem ein verschlüsseltes LVM-Volume des Laptops heranzuziehen. Siehe die Links unten.

Fazit

Eine Sicherheit allein durch den Einsatz verschlüsselter Datei-Container gibt es in unserem Szenario nicht. Auch unter Linux nicht! Egal, ob die Container remote auf gehosteten Servern oder lokal vorhanden sind. Vielmehr ist für eine vollständige Verschlüsselung aller Partitionen des Client-Systems zu sorgen, wobei auf den Einsatz von SSDs im Idealfall verzichtet werden sollte.

Wir haben hier nur einen kleinen Teil von Sicherheitsaspekten betrachtet. Das, was wir diskutiert haben, hätte man in ähnlicher Weise aber auch für andere Betriebssysteme aufschreiben können. Sicherheit ist ein weit komplexeres Thema als nur eine Frage des Betriebssystems. Das gute an Linux ist jedoch, dass man hier alle notwendigen Tools zur Verbesserung der Sicherung geheimzuhaltender Information als Opensource Programme und kostenfrei vorfindet.

Also: Verschlüsselt eure geheimzuhaltenden Informationen. Nicht zuletzt, wenn ihr im Auftrag von Unternehmen unterwegs seid! Verlangt euren (Linux-) Admins entsprechende Lösungen ab. Aber hört nicht auf, Sicherheit zu hinterfragen. Sie ist immer relativ! Auch unter Linux!

Links - weitere Infos

Grundlegende Probleme der Verschlüsselung reiner Datei-Container-Verschlüsselung
https://www.computerwissen.de/it-sicherheit/web-security/artikel/verschluesselte-container-bieten-ihnen-keinen-zuverlaessigen-schutz.html
https://www.cs.washington.edu/research/security/truecrypt.pdf

SSDs mit Wear-Leveling und Sicherheitsprobleme
http://www.zdnet.com/article/ssd-security-the-worst-of-all-worlds/
https://www.pcwelt.de/ratgeber/Datensicherheit-6581465.html
https://www.computerwoche.de/a/die-geheimen-schwaechen-der-ssd,2501912,4
https://www.computerbase.de/forum/showthread.php?t=1395284
https://forum.truecrypt.ch/t/ssds-not-appropriate-for-encryption/486
https://www.veracrypt.fr/en/Wear-Leveling.html
https://www.ghacks.net/2011/02/23/solid-state-drives-and-encryption-a-no-go/
https://debianforum.de/forum/viewtopic.php?t=163274
http://news.softpedia.com/news/systemd-232-supports-veracrypt-encrypted-partitions-adds-60-improvements-509945.shtml

Performance SSDs - Encryption - TRIM
https://security.stackexchange.com/questions/61089/can-truecrypt-encrypt-ssds-without-performance-problems
https://www.heise.de/ct/hotline/Linux-Verschluesselte-SSD-trimmen-2405875.html
http://mgessat.com/verschluesselungssoftware-veracrypt-unabhaengige-ueberpruefung-abgeschlossen/
http://media-addicted.de/ssd-and-truecrypt-durability-and-performance-issues/744/
http://asalor.blogspot.de/2011/08/trim-dm-crypt-problems.html

Sicheres Löschen von Files auf konventionellen HDDs mit Wipe
[funktioniert nicht mit Flash-Speichern/SSDs]
https://superuser.com/questions/19326/how-to-wipe-free-disk-space-in-linux
https://tails.boum.org/doc/encryption_and_privacy/secure_deletion/index.en.html
https://wiki.ubuntuusers.de/Daten_sicher_l%C3%B6schen/
https://www.cyberciti.biz/tips/linux-how-to-delete-file-securely.html

Vollständiges Löschen von SSDs?
https://wiki.ubuntuusers.de/SSD/Secure-Erase/
http://www.pc-magazin.de/ratgeber/festplatte-restlos-loeschen-sicher-saeubern-ssd-secure-erase-anleitung-hdd-3196204.html#
https://wiki.ubuntuusers.de/SSD/Secure-Erase/

Bereinigen des RAMs, Caches, SWAP spaces
https://www.tecmint.com/clear-ram-memory-cache-buffer-and-swap-space-on-linux/

LVM und verschlüsselte Volumes
https://debianforum.de/forum/viewtopic.php?f=12&t=127012

KVM Gastsysteme auf verschlüsselten Volumes
https://www.ibm.com/support/knowledgecenter/en/linuxonibm/liaat/liaatkvmsecencrypt.htm
https://www.ibm.com/support/knowledgecenter/linuxonibm/liaat/liaatsecurity_pdf.pdf
https://security.stackexchange.com/questions/20334/memory-dumping-cause-for-concern-in-virtualization
https://forums.whonix.org/t/how-useful-is-in-guest-encryption/1253
https://security.stackexchange.com/questions/29535/full-disk-encryption-within-a-vm-how-secure-is-it/29538#29538

Ein paar Aspekte von LUKS
https://wiki.ubuntuusers.de/LUKS/Containerdatei/
https://www.pcwelt.de/ratgeber/Ausgesperrt__Luks_mit_Ersatzschluessel_oeffnen-Linux-8664088.html
http://www.bocekm.com/enlarge-luks-encrypted-logical-volume/

Backups mit LUKS und SSHFS
https://ruderich.org/simon/notes/encrypted-remote-backups

KDE, Plasma 5, sporadisch 100% CPU-Verbrauch und/oder kein Input in Terminalfenster – Workaround

Offenbar geistert in KDE/Plasma5 ein alter Bug herum, der mit animierten Icons im Systemabschnitt der Kontroll-Leiste zu tun zu haben scheint. Über die Ursachen wird spekuliert; in einigen Artikeln zu dem Thema wird OpenGL-Treibern die Schuld gegeben. In anderen einem intrinsischen Bug in der Zusammenarbeit mit Qt. Egal. Die zugrunde liegenden Bugs haben nach meiner Erfahrung mehrere Auswirkungen:

  1. Ab und zu schießt die Belastung auf mindestens einem CPU-Core auf 100% und verbleibt dort.
  2. Keyboard-Eingaben in Terminal-Fenster oder andere bereits offene Input-Felder werden nach einer Arbeitspause ignoriert.
  3. Bei einem Übergang in einen Screen-Saver-Zustand oder gar StandBy-Modus geht ggf. die Verbindung zur Maus oder zum Keyboard verloren.

Das Auftreten jedes der Fehler ist recht sporadisch. Wenn Fehler 1 und 2 passieren und man noch irgendein neues Terminalfenster starten kann, hilft die Eingabe von

myself@mytux:~> killall plasmashell 
myself@mytux:~> kstart plasmashell --shut-up 

um die Probleme für die aktuelle (!) Plasma-Sitzung zu beseitigen.

Es kann gut sein, dass die Ursachen für die beschriebenen Probleme unterschiedlich sind, aber seit dem Anwenden eines bestimmten Workarounds sind gleich alle 3 Probleme nicht mehr aufgetreten. Der Workaround ist nicht auf meinem Mist gewachsen; er ist hier zu finden:

https://www.linuxquestions.org/questions/linuxquestions-org-member-success-stories-23/plasmashell-high-cpu-load-fix-plasma-5-9x-kde-4175606972/

Dort wird kurz und knapp beschrieben, wie man die Animationen für "Notification Icons" beendet:

Open file /usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/NotificationIcon.qml
Search for line "running: visible" in "PlasmaComponents.BusyIndicator" section and change it in "running: false".

Siehe auch den letzten Kommentar unter:
https://forum.kde.org/viewtopic.php?f=309&t=136964

Das beenden der Animation hat zwar Informationsnachteile; aber mir ist das lieber als die oben beschriebenen Probleme. Ich lege diesen Workaround in diesem Sinne deshalb jenen Lesern ans Herz, die von selbigen Problemen geplagt werden.

Links
https://askubuntu.com/questions/846781/why-is-plasmashell-using-100-cpu
https://bugs.kde.org/show_bug.cgi?id=356479

https://bugs.kde.org/show_bug.cgi?id=311799
https://github.com/psi-im/psi/issues/249
https://devtalk.nvidia.com/default/topic/995017/linux/high-cpu-usage-of-x-and-kwin-on-opensuse-leap-42-2/
https://bugs.kde.org/show_bug.cgi?id=376966
https://bbs.archlinux.org/viewtopic.php?id=216797
https://ubuntuforums.org/showthread.php?t=2339471
https://bbs.archlinux.org/viewtopic.php?id=218348
https://www.lifewire.com/kubuntu-p2-2202573