Betriebssystem So wird Embedded Linux sicher

Die Anforderungen an Embedded-Systeme in der Daten- und Betriebssicherheit sowie der System-Integrität sind in den vergangenen Jahren deutlich angestiegen. Völlig zurecht, denn das Gefahrenpotenzial durch Angriffe auf moderne Steuerungssysteme ist durchaus real. Als Grundlage zum Design sicherer Systeme werden vom Bundesministerium für Sicherheit in der Informationstechnik (BSI) wichtige Leitfäden herausgegeben, die immer wieder darauf hinweisen, dass Sicherheit nicht erst an den Systemgrenzen zur Außenwelt beginnt. Zu den Leitfäden gehören zum Beispiel: Deutsche IT-Sicherheitskriterien (ITS) oder die Common Criteria (CC). Beide Dokumente beschreiben auch Basis-Sicherheitskonzepte, die das gesamte System durchziehen. Zum Implementieren dieser Sicherheitskonzepte kann der Entwickler auf den reichhaltigen Funktionsumfang von Linux zurückgreifen. Manche Anforderungen in den genannten Dokumenten lassen sich 1:1 auf Komponenten in Linux abbilden.

Linux ist, wie andere Unix-artige Betriebssysteme auch, als ein Multi-Tasking-/Multi-User-Betriebssystem ausgelegt. Multi-Tasking bedeutet in diesem Kontext, dass mehrere Applikationen parallel prozessiert werden können. Der damit einhergehende Schutz der Ressourcen einer Applikation gegenüber anderen laufenden Anwendungen passiert dabei transparent für den Entwickler und gehört mittlerweile zum Standard von Embedded-Systemen.

Anders sieht es da bei der Multi-User-Fähigkeit aus. Diese System-Eigenschaft ermöglicht, nicht nur Speicher- und Codebereiche einzelner Applikationen gegeneinander abzugrenzen, sondern auch die Interaktion mit dem Betriebssystem und den verwalteten Ressourcen zu regulieren. Wie dieses Feature genutzt werden kann, um den Schaden eines Angriffs zu minimieren, soll das folgende Beispiel zeigen.

Mehrbenutzerverwaltung

In diesem Beispiel soll die Steuerung neben ihrer eigentlichen Funktion die Prozess-Daten über ein Web-Interface zur Verfügung stellen, das eine Abfrage via Internet-Browser ermöglicht. Dazu läuft auf der Steuerung neben der Kontroll-Applikation noch ein Web-Server. Die Kontroll-Applikation sammelt die Daten und speichert sie in einer Datenbank-Datei, aus der sich der Web-Server bedient. Er stellt hier also ein Read-Only-Interface zu einem öffentlichen Netzwerk dar. Leider werden immer wieder Web-Server durch Angreifer kompromittiert. Durch gezielte Attacken erlangt der Angreifer damit die Möglichkeit, mit den Rechten des Web-Servers auf dem System zu agieren.

Häufig laufen beide Prozesse, Kontroll-Applikation und Webserver, mit allen Berechtigungen auf dem System – sozusagen als Super-User „root“. Dabei unterliegt keiner der beiden Prozesse irgendwelchen Einschränkungen durch das System. Kommt es dann zur Kompromittierung des Web-Servers, kann der Angreifer das komplette System übernehmen. In der Praxis bedeutet das: Er kann nicht nur die Daten manipulieren, sondern auch Einfluss auf die Kontroll-Applikation nehmen.

Mit Hilfe der Multi-User-Funktionalität von Linux lässt sich zwar der Angriff auf den Web-Server nicht verhindern, aber die Auswirkungen können minimiert werden. Der Web-Server sollte in jedem Fall unter der Berechtigung eines nicht voll-privilegierten Benutzers gestartet werden, ebenso die Kontroll-Applikation. Im Beispiel wird für den Web-Server der Benutzer „www“ und für die Kontroll-Applikation der Benutzer „control“ angelegt. Der Super-User „root“ kommt nur noch bei Wartungszwecken zum Einsatz.

Die Benutzer werden nun mit den benötigten Berechtigungen ausgestattet, „control“ erhält Lese-/Schreib-Berechtigung auf die Datenbank-Datei, während der Benutzer „www“ nur Lese-Rechte darauf erhält. Des Weiteren werden die Berechtigungen aller anderen Ressourcen von Benutzer „control“ so gesetzt, dass der Benutzer „www“ darauf keinerlei ­Zugriff hat. Kommt es nun bei einem Angriff zur Kompromittierung des Web-Servers, so kann der Angreifer nur lesend auf die Datenbank-Datei zugreifen. Eine direkte Einflussmöglichkeit auf die Kontroll-Applikation ist nicht ohne weiteres möglich.

Der richtige Einsatz des Multi-User-Bordmittels hat dazu geführt, dass sich die Sicherheit des Gesamt-Systems drastisch erhöht hat, ohne die Funktionalität einzuschränken – und das mit nur geringem Aufwand. Eine funktionale Mehrbenutzerverwaltung ist einer der Grundpfeiler in den Common Criteria des BSI. Über das oben beschriebene Szenario hinaus bietet sie nicht nur Schutz gegen Angriffe, auch für ein rollenbasiertes Zugriffskonzept und Aspekte des Datenschutzes ist sie eine wichtige Grundlage.

Access Control Lists

Wenn die Basis-Funktionen der Mehrbenutzerverwaltung die Anforderungen des Systemkonzepts nicht ganz erfüllen, dann kann der Entwickler auf weitere Konzepte in Linux zurückgreifen. So bieten die Access Control Lists (ACL) die Möglichkeit, den Zugriff auf Dateien und anderer Ressourcen sehr granular zu manipulieren. Eine Ressource nur bestimmten Benutzern einer oder mehrerer Gruppen zur Verfügung zu stellen lässt sich nur mit erheblichem Aufwand mit dem normalen Gruppenkonzept verwirklichen. In einem solchen Fall kann eine ACL dieser Ressource jeden Benutzer explizit aufführen, jeweils sogar mit eigenen Zugriffs-Attributen.

Extended Attributes

So wie die Access Control Lists das Benutzerkonzept erweitern, so ergänzen die Extended Attributes „attr“ die Zugriffs-Attribute auf Dateien und andere Ressourcen. Die Basis für den Datei-Zugriff bilden die Attribute „read“, „write“ und „execute“. Diese können gesetzt sein für den Eigentümer der Datei „user“, die Eigentümer-Gruppe „group“ und alle anderen „other“, Entsprechend dieser Attribute kann nun auf die Datei zugegriffen werden. Soll der Zugriff über die Basis-Funktionen „read“, „write“ und „execute“ hinaus geregelt werden, so bieten die Extended Attributes unter anderem folgende Erweiterung:

• append only (a): Ist dieses Attribut gesetzt, so kann eine Datei vom Benutzer zwar gelesen und geschrieben werden, aber nicht gekürzt. Dies bietet sich zum Beispiel für Logdateien von Netzwerk-Services an. Der Service kann dann Ereignisse wie etwa einen fehlgeschlagenen Login-Versuch in die Logdatei schreiben. Ein Angreifer, der nach einem Einbruch seine Spuren in der Logdatei beseitigen möchte, kann die einmal geschriebenen Ereignisse aber nicht ohne weiteres aus der Logdatei herauslöschen.

• immutable (i): Dieses Attribut verhindert, dass das File in irgendeiner Weise verändert werden kann. Es kann nicht beschrieben oder gelöscht werden, auch das Umbenennen oder Anlegen von Links auf eine solche Datei ist nicht möglich.

• secure deletion (s): Wird eine Datei gelöscht, bei der dieses Attribut gesetzt ist, dann werden alle Blöcke der Datei mit dem Wert 0x00h überschrieben.

Die letzten beiden Attribute eigenen sich unter an­derem für die Ablage von Kryptographie-Schlüsseln oder -­Zertifikaten.

Sicherheitsfunktionen bitte nutzen!

Nur das Vorhandensein von Sicherheits-Funktionen bringt noch keine Sicherheit. Eine nicht genutzte Mehrbenutzerverwaltung in Steuerungen ist hier leider ein viel zu häufig anzutreffendes, mahnendes Beispiel. Die Sicherheitsfunktionen von Linux können ihre Wirkung aber nur dann entfalten, wenn sie auch genutzt werden.