Masterarbeit Fachhochschul-Studiengang Master Informatik

Transkript

1 Fachhochschule Vorarlberg University of Applied Sciences Masterarbeit Fachhochschul-Studiengang Master Informatik Trusted Boot und Mandatory Access Control: Vertrauenswürdige Ver- und Bearbeitung von sensiblen und privaten Prozessen und Daten in Fremdsystemen, wie z.b. Cloud-Umgebungen ausgeführt von Philipp Rusch, BSc ( ) Zur Erlangung des akademischen Grades Master of Science in Engineering, MSc Dornbirn, im Juli 2014 an der Fachhochschule Vorarlberg betreut durch Dipl.-Ing. Armin Simma durchgeführt bei inet-logistics GmbH in 6850 Dornbirn betreut durch Dipl.-Ing. Klaus Battlogg

2 Kurzfassung Diese Arbeit thematisiert die Möglichkeiten zur Einschränkung von privilegierten Benutzern ( Superusern ) und die Attestierung der Vertrauenswürdigkeit eines Computer-Systems. Zur Einschränkung der privilegierten Benutzer wurde das Mandatory Access Control-Framework SELinux verwendet. Die Umsetzung der Vertrauenswürdigkeitsbescheinigung orientiert sich an der Spezifikation der Trusted Computing Group, welcher die Verwendung des Trusted Platform Modules zugrunde liegt. Nach einer theoretischen Einführung in die Themen der Zugriffskontrollstrategien und deren Umsetzung und Funktionsweise wird ein Überblick über den Aufbau des Trusted Computings gegeben. Im Anschluss daran wird die beispielhafte Implementierung mittels Open- Source Software vorgestellt. Um Superuser einzuschränken, wird die Multi Category Security von SELinux verwendet. Zusätzlich werden noch zwei weitere Möglichkeiten beschrieben, welche ein unbemerktes Ändern der Sicherheitsrichtlinie verhindern. Wie die verschiedenen Open-Source Werkzeuge installiert und konfiguriert werden müssen, um eine Trusted Computing Platform zu erstellen, wird im Anschluss an die SELinux Umsetzung beschrieben. Die Ergebnisse dieser Implementierungen werden in einem eigenen Abschnitt thematisiert. Dabei werden Vor- und Nachteile und auftretende Probleme näher beschrieben. Zum Abschluss werden alternative Technologien, mit welchen ebenfalls eine Trusted Computing Platform geschaffen werden kann, vorgestellt. Beschrieben werden dabei Intels Trusted Execution Technology, das Open- Source Softwarepaket Trusted-Boot und ein Attestierungswerkzeug namens OpenAttestation. Abschließend wird ein Fazit gezogen und ein Ausblick über die weitere Verwendung der Werkzeuge gegeben.

3 Abstract This thesis explores the possibilities for confining privileged users and the attestation of trustworthiness of a computer system. To confine privileged users the Mandatory Access Control framework SELinux was used. The implementation of the trustworthiness certification process is in keeping with the specifications of the Trusted Computing Group. These specifications are based on the use of the Trusted Platform Module. After a theoretical introduction to the issues of access control policies and their implementation and operation, this paper gives an overview of the structure of the Trusted Platform Computing. Following this, the prototype is presented by open source software. To restrict Superusers, the Multi Category Security functionality of SELinux is used. This paper further describes two additional options, meant to prevent the undetectable changing of the security policy. Further to the section treating the SELinux implementation, the paper provides a comprehensive how-to of the installation and configuration of the various open-source tools to create a Trusted Computing Platform. The results of these implementations are discussed in a separate section. Here, the advantages, disadvantages and problems are described in detail. Finally, alternative technologies, with which a Trusted Computing Platform can also be created, are presented. This covers Intel s Trusted Execution Technology, the open-source software package Trusted-Boot and an attestation tool called OpenAttestation. Finally, conclusions are drawn, and an outlook on the further use of the tools is given.

4 Inhaltsverzeichnis 1 Einleitung Nutzen für den Auftraggeber Ziele dieser Arbeit Technologieübersicht Testsystem Mandatory Access Control SELinux Linux Security Modules Funktionsweise Richtlinien Richtlinien entwickeln Trusted Computing Trusted Computing System TPM Root of Trust Chain of Trust Trusted Software Stack Integritätsmessung Schlüsselarten im TPM Implementierung Mandatory Access Control Abschaltung der Richtlinie verhindern Superuser beschränken SELinux-Benutzer anlegen sysadm_secadm-modul deaktivieren Trusted Platform Computing TPM im BIOS und Kernel aktivieren... 35

5 3.2.2 TrustedGrub Integrity Measurement Architecture Remote Attestation Ergebnisse Mandatory Access Control MLS-Richtline mit Kategorien SELinux-Modul entwickeln Role Based Access Control Virtualisierung TrustedGrub Integrity Measurement Architecture Remote Attestation Verwandte Technologien Intel Trusted Execution Technology Funktionsweise Wurzel des Vertrauens mit TXT Trusted Boot OpenAttestation Architektur Komponenten Anwendungsfall Zusammenfassung und Ausblick... 69

6 1 Einleitung Das Unternehmen inet-logistics hat sich am europäischen Markt als Anbieter von Logistiklösungen als Software as a Service etabliert. Der Schwerpunkt der unternehmerischen Tätigkeiten liegt derzeit im Deutschland-Österreich- Schweiz (DACH)-Markt. Zusätzlich wurden in den vergangenen Jahren Niederlassungen in Thailand und Brasilien eröffnet, um diese Märkte entsprechend schneller bedienen zu können. Um auch in Zukunft für weitere Expansionen in den neu zu erschließenden Märkten gewappnet zu sein, wird bei inet-logistics die Möglichkeit in Betracht gezogen, die Software auf angemieteten Rechnern in einer virtuellen Umgebung zu betreiben. Da sich angemietete Rechner nicht in der selbst kontrollierbaren Sphäre befinden und es in der Vergangenheit mehrere Skandale zur Datensicherheit bzw. deren Missbrauch gegeben hat, soll in dieser Arbeit untersucht werden, mit welchen Technologien eine vertrauenswürdige Plattform geschaffen werden kann. Die in dieser Arbeit hauptsächlich besprochenen Technologien sind Trusted Computing-Funktionalitäten und Zugriffskontroll-Mechanismen auf Basis von Mandatory-Access-Control (MAC)-Implementierungen. Konkret wird dabei die Umsetzung der Trusted Computing Group (TCG)-Spezifikation für ein Trusted Platform Module (TPM) betrachtet. Mit diesem Modul soll es ermöglicht werden, ein erhöhtes Maß an Vertrauenswürdigkeit zu erreichen. Einem Hardware-Bauteil wird grundsätzlich mehr vertraut als Software. Dies liegt daran, dass solch spezielle Sicherheits-Hardware nicht nachträglich verändert werden kann. Im Gegensatz dazu kann Software mit sehr viel mehr und einfacheren Mitteln attackiert werden. Zur Umsetzung der Zugriffskontrolle wird in dieser Arbeit das von der National Security Agency (NSA) entwickelte Security Enhanced Linux (SELinux) verwendet. Dieses Werkzeug ermöglicht es - auch privilegierte - Benutzer am Zugriff auf sensible Daten zu hindern. Da in der Praxis nichts als hundertprozentig sicher angesehen werden sollte, wäre es falsch, zu sagen, dass mittels 7

7 dieses Werkzeugs ein Zugriff ausgeschlossen werden kann. Jedoch soll der dafür aufzubringende Aufwand so hoch wie möglich sein. Bisher wurden zur Absicherung virtueller Umgebungen sehr viele Anstrengungen unternommen. Das Hauptaugenmerk lag dabei darauf, wie die Gast-Systeme auf einem Host-System voneinander geschützt werden können oder aber auch der Zugriff auf das zu Grunde liegende Virtualisierung- und Betriebs-System verhindert werden kann. Es gibt bis dato jedoch noch keine Implementierung, welche den privilegierten Root- System-Benutzer davor hindert, auf diese Gast-Systeme zuzugreifen und Manipulationen an diesen durchzuführen. Dieses Szenario ist in Abbildung 1 dargestellt. Host-System Superuser? Virtuelle Maschine 1 Virtuelle Maschine 2 Abbildung 1: Superuser-Zugriff auf die Gast-Systeme einschränken Da inet-logistics seine Server als virtuelle Maschinen-Instanzen betreiben will und sich darauf sensible Daten befinden, sollen Administratoren des Host- System Anbieters so weit wie möglich eingeschränkt werden. 8

8 1.1 Nutzen für den Auftraggeber Durch die ständige Akquisition neuer Kunden steht inet-logistics vor neuen Herausforderungen. Diese betreffen nicht nur das betriebswirtschaftliche Umfeld des Unternehmens sondern vor allem auch den technischen Betrieb der Applikationen für Kunden. Da sich unter den Kunden global tätige Unternehmen befinden, wachsen die Ansprüche an den Betrieb, die Verfügbarkeit und die Latenzzeiten. Um diesen Umständen gerecht zu werden, ist es in den nächsten Jahren möglich, dass die von inet-logistics entwickelten Applikationen nicht nur in Österreich betrieben werden sollen. Um auf diesen Umstand vorbereitet zu sein, soll mit dieser Arbeit Erfahrung im Betrieb der Applikationen auf virtuellen Umgebungen gesammelt werden. Der Fokus liegt dabei nicht auf dem Betrieb der Applikation selbst, sondern auf den im nächsten Abschnitt beschriebenen Zielen. 1.2 Ziele dieser Arbeit Im Rahmen dieser Arbeit wird untersucht, welche Möglichkeiten es gibt, ein Host-System so abzusichern, dass gegenüber einem Kunden die Aussage getroffen werden kann, dass sich das System in einem integren Zustand befindet. Dabei werden die folgenden Ziele verfolgt: - Den Zugriff auf die virtuellen Server-Instanzen soweit wie möglich vor Zugriffen nicht vertrauenswürdiger Benutzer zu schützen. - Die Möglichkeit, eine Aussage darüber treffen zu können, dass das zu Grunde liegende Host-System nicht korrumpiert wurde und sich in einem vertrauenswürdigen Zustand befindet. Der Kunde, in diesem Fall inet-logistics, soll die Möglichkeit haben, vor dem Kopieren oder Starten des virtuellen Servers zu überprüfen, ob sich das Host-System in einem akzeptierten Zustand befindet. Dies wird dadurch erreicht, dass vor der Erstinbetriebnahme ein Hash-Wert des Host-Systems erstellt wird und anschießend im sicheren Speicherbereich des Servers innerhalb des TPM - abgelegt wird. Inet-logistics erhält ebenfalls eine Kopie dieses Hash Wertes über einen sicheren Kanal. Soll nun die erste Kopie der virtuellen Instanz auf dem Server abgelegt werden, wird dieser Hash-Wert 9

9 über einen ebenfalls sicheren Kanal gegengeprüft. Der Kopiervorgang wird nur im Fall eines positiven Vergleichs angestoßen. Im nachfolgenden Kapitel wird ein Überblick über die in dieser Arbeit hauptsächlich besprochenen und in der Umsetzung verwendeten Technologien gegeben. 10

10 2 Technologieübersicht In diesem Kapitel wird eine Übersicht über die zum Einsatz kommenden Technologien gegeben. Dabei liegt der Fokus auf den theoretischen Konzepten, welche hinter diesen Technologien stehen. Zuerst wird das Testsystem, welches zum Einsatz kommt, beschrieben und im Anschluss das Konzept der Mandatory Access Control an Hand der Implementierung in SELinux erläutert. Anschließend wird das Konzept des Trusted Platform Computings (TPC) und seine Funktionen beschrieben. 2.1 Testsystem Zum Zeitpunkt der Ausarbeitung dieser Arbeit wird bei inet-logistics das Betriebssystem RedHat Enterprise Linux 6 (RHEL) eingesetzt. Auf Grund dieser Tatsache wurde für die Erstellung der Arbeit das Betriebssystem Fedora Linux in Version 20 verwendet. Bei der Entwicklung dieses Betriebssystems gibt es eine Zusammenarbeit zwischen RedHat und den Entwicklern/innen der freien Gemeinde (vgl. Red Hat Inc. 2014). RedHat übernimmt die neu getesteten Möglichkeiten aus der Fedora Distribution nach einer Testphase in sein Enterprise-Betriebssystem. Für Fedora ist es nicht möglich, eine kommerzielle Unterstützung zu erhalten. Als Hardware wurde ein Hewlett-Packard EliteBook 8570p eingesetzt, welches standardmäßig einen TPM-Chip beinhaltet. (Vgl. Hewlett-Packard Development Company, L.P 2012, S. 9) 11

11 2.2 Mandatory Access Control In diesem Abschnitt werden zuerst zwei Zugriffskontrollstrategien betrachtet, welche unter Unix-Betriebssystemen zum Einsatz kommen. Discretionary Access Control In klassischen Unix-und Linux-Betriebssystemen kommt eine Discretionary Access Control (DAC) zum Einsatz. Das Konzept der DAC beruht auf den Identitäten des/der Akteurs/in. Der Zugriff auf Objekte wird somit nur an Hand von diesen Identitäten gewährt oder verweigert. Identitäten können der/die Benutzer/in oder auch die Gruppenzugehörigkeit des/der Akteurs/in sein. Diese Zugriffskontrollstrategie ist in sehr vielen Betriebssystemen zu finden. Zur Erläuterung dieser Strategie, wird die /etc/shadow-datei als Beispiel herangezogen, welche Passwörter und Benutzerinformationen enthält: # ls -l /etc/shadow -rw root root 943 Mar 6 07:46 /etc/shadow Listing 1: Die Datei /etc/shadow mit ihren DAC Zugriffsrechten In Listing 1 ist zu sehen, dass nur der Besitzer in diesem Fall der root- Benutzer- Lese- und Schreibrechte auf die /etc/shadow-datei besitzt. Ohne zusätzliche Schutzmechanismen ist es für jeden Prozess, welcher unter dem Root Kontext läuft, möglich, auf die Datei lesend und schreibend zuzugreifen. Die shadow-datei ist ein typisches Beispiel für eine sensible Datei auf einem System, welche speziell vor Missbrauch geschützt werden sollte. Sobald Benutzer/innen Zugriff auf diese Datei haben, kann diese kopiert oder versendet werden und Angriffe auf die verschlüsselten Passwörter gestartet werden. (Vgl. Sven Vermeulen 2013, S. 8) Benutzer/innen sind nicht die einzige Bedrohung für ein System. Viele Software-Dämonen laufen unter dem Root-Kontext und verfügen somit über signifikante Privilegien auf dem System. Fehler innerhalb der Software können dazu führen, dass Informationen abgefragt oder Kommandos über diesen Dämon ausgeführt werden können. Beispiele für solch privilegierte Software sind Backup- oder auch Monitoring-Werkzeuge, welche sehr häufig mit Root-Rechten gestartet werden müssen. (Vgl. ebd. 2013, S. 8) 12

12 Mandatory Access Control Die MAC-Strategie stellt das Gegenstück zur DAC-Strategie dar. Diese basiert auf systemweit gültigen Regeln, welche unabhängig von der Identität des/der Benutzers/in angewendet werden. Solch eine Implementierung wird als zusätzliche Schicht im System eingezogen. Sie ermöglicht dem/der Administrator/in, alle Zugriffe und Kommunikationskanäle explizit freizugeben. Diese zwingende Zugriffskontrolle wird vom zu Grunde liegenden System durchgeführt und kann einzig von Administratoren/innen konfiguriert werden. Im Gegensatz zur DAC Strategie können somit Benutzer/innen und Prozesse diesen Mechanismus nicht mehr umgehen oder ändern SELinux Bei SELinux handelt es sich um eine konkrete Umsetzung der MAC- Strategie. Entwickelt wurde SELinux ursprünglich von der NSA aus den Vereinigten Staaten von Amerika. Im Dezember 2000 wurde SELinux unter der GNU Public License von der NSA veröffentlicht (vgl. Thomas Wolfe 2012). 13

13 2.2.2 Linux Security Modules Alle Regeln, welche von SELinux beim Start des Systems geladen werden, sind in einer Richtlinie definiert. Für die Umsetzung der Regeln ist der Kernel verantwortlich, welcher diese Aufgabe mittels den Linux Security Modules (LSM) durchführt. User space Prozess System call Fehler Daten suchen Fehlerüberprüfung Keine Fehler Zugriff verweigert Zugriff verweigert Kernel space DAC Überprüfungen DAC Ok LSM Hook LSM Ok Aufruf Ok? LSM retourniert ja/nein Linux Security Module (Beispiel SELinux) OK System Call Ergebnis retournieren Abbildung 2: Überblick der LSM Integration in den Linux Kernel (vgl. Sven Vermeulen 2013, S. 10) Die LSM wurden 2003 in den Linux-Kernel übernommen. Es handelt sich dabei um ein Framework, welches Hooks innerhalb des Kernels bereitstellt. Wie in Abbildung 2 ersichtlich ist, dient ein System-Call-Aufruf als Einstiegspunkt. Mittels dem LSM Hook ist es möglich, Funktionen aufzurufen, welche die Sicherheit (beispielsweise durch SELinux) überprüfen. Innerhalb des Security Moduls wird überprüft, ob der gewünschte Aufruf gestattet ist oder nicht. LSM selbst stellt keine Sicherheitsfunktionalität zur Verfügung, 14

14 sondern verlässt sich auf Implementierungen, welche auf der LSM- Funktionalität aufsetzen. (Vgl. Sven Vermeulen 2013, S. 10) Funktionsweise Wie einführend erwähnt, verwendet das DAC-System die Identität des/der Benutzers/in oder Prozesses sowie die dazugehörenden Rechte der Datei für die Zugriffskontrolle. SELinux hingegen nutzt einen Security- Context. unconfined_u unconfined_r unconfined_t s0-s0:c0.c1023 SELinux user SELinux role SELinux type Sensitivity level Abbildung 3: Aufbau des SELinux Security-Contexts (vgl. Sven Vermeulen 2013, S. 14) Wie in Abbildung 3 ersichtlich, besteht dieser Kontext aus SELinux-Benutzer, SELinux-Rolle, SELinux-Typ und dem Sensitivity Level. Der Aufbau des Kontexts sieht sowohl für den/die Benutzer/in als auch für Objekte identisch aus. Über Regeln, welche im nächsten Kapitel näher erläutert werden, wird der Zugriff auf System-Objekte erlaubt oder verweigert. Jedes Subjekt (Benutzer/in oder Prozess) und jedes Objekt (Datei, Verzeichnis oder Socket) wird mit einem Security-Context versehen. (Vgl. Ralf Spenneberg 2008, S. 141) Security Context Der Aufbau eines solchen Kontexts, sieht wie folgt aus: SELinux Benutzer/in: Unter SELinux können nochmals Benutzer/innen angelegt werden. Diese müssen jedoch nicht dem/der Linux-Benutzer/in entsprechen. SELinux verwaltet intern eine eigene Benutzerdatenbank. Es ist möglich, dass mehrere Linux- Benutzer/innen denselben SELinux-Benutzer verwenden. (Vgl. ebd 2008, S. 141) 15

15 SELinux Rolle: SELinux-Benutzer/innen haben mindestens eine Rolle zugewiesen. Es ist auch möglich, dass dem/der Benutzer/in mehrere Rollen zugewiesen wurden, so dass auch in SELinux zwischen Rollen gewechselt werden kann. Dies kann beispielsweise für administrative Aufgaben sinnvoll sein. (Vgl. ebd. 2008, S. 141) SELinux Type: Der Typ ist das wesentlichste Attribut bei SELinux, da alle Benutzer/innen und Objekte mit einem Typ versehen werden. SELinux basiert auf Type-Enforcement, welches mit den Regeln aus der Richtlinie die Zugriffsüberprüfung durchführt. Somit wird mittels Type Attribut festgestellt, ob ein Zugriff erlaubt ist oder nicht. Sich ähnliche Subjekte und Objekte können mit dem gleichen Typ versehen werden, um sie so mit den gleichen Berechtigungen auszustatten. Im Kontext von SELinux wird der Typ eines Subjekts sehr oft als Domäne bezeichnet, was die Unterscheidung zwischen Subjekten und Objekten erleichtert. (Vgl. ebd. 2008, S. 141) Sensitivity Level: Dieses Feld besteht in Wirklichkeit aus zwei Feldern: Sensitivity und Compartment oder Category. Jedes Objekt besitzt genau eine Multi-Level-Security (MLS)-Markierung. Der in Abbildung 3 zu sehende MLS-Bereich s0-s0 ist für die MLS- Richtlinie relevant und wird mittels eines SELinux-Constraints überprüft. Der zweite Bereich c0.c1023 beschreibt die Kategorien, welche dem Objekt zugeordnet sind. Diese Kategorien werden von der Multi Category Security (MCS) verwendet, welche in Abschnitt erläutert wird. (Vgl. ebd. 2008, S. 152) 16

16 Type Enforcement Die Umsetzung der Regeln mittels Type-Enforcement soll mit dem eingangs erwähnten Beispiel der /etc/shadow-datei erläutert werden. Die /etc/shadow-datei enthält die gehashten Passwörter aller Systembenutzer/innen und ist daher besonders schützenswert. Wäre es jedem/jeder Benutzer/in möglich, die gehashten Passwörter zu lesen, könnten diese mit einem Crack-Programm attackiert werden. Jeder/jede Benutzer/in soll die Möglichkeit haben, sein/ihr Passwort zu ändern, während der/die Root-Benutzer/in sämtliche Passwörter ändern darf. Um diese Funktionalität bereitzustellen, enthält der Befehl passwd einen Mechanismus, mit dem ermittelt wird, ob es sich beim aufrufenden Benutzer um root oder um einen normalen Benutzer handelt. Es benötigt jedoch noch weitere Rechte, damit auch ein/eine nicht privilegierter/e Benutzer/in passwd benutzen kann, da der Prozess noch über zu wenig Rechte verfügt, um die /etc/shadow-datei zu editieren (vgl. ebd. 2008, S. 146). Die nötigen Rechte werden mit dem SetUID-Recht vergeben. Dieses Recht erlaubt es dem aufrufenden Prozess, in diesem Fall passwd, seine Identität - zu jener des Besitzers der Binärdatei - zu wechseln. Beim Befehl passwd ist das root. Somit erhält der Prozess passwd das Recht, die Datei /etc/shadow zu ändern. (Vgl. ebd. 2008, S. 147) Da es auf einem Linux-System mehrere Dateien gibt, die über das SetUID- Recht verfügen, wäre es möglich, über eine solche Datei Zugriff auf die /etc/shadow-datei zu erhalten. Mit dem Einsatz von SELinux kann dies verhindert werden, da jeder Zugriff explizit freigegeben werden muss. Man benötigt zur Konfiguration folgende Dinge: Einen Security-Context für die zu ändernde Datei /etc/shadow. Einen Security-Context für den aufrufenden Prozess passwd. Eine Allow-Regel, welche den Zugriff vom Prozess auf die Datei erlaubt. 17

17 # Security-Context /etc/shadow: system_u:object_r:shadow_t # Security-Context des Prozesses: user_u:user_r:passwd_t # Allow-Regel für den Zugriff: allow passwd_t shadow_t:file rw_file_perms; Listing 2: Security-Context für die /etc/shadow-datei (vgl. ebd. 2008, S. 147) Bei der allow-regel in Listing 2 fällt auf, dass hinter dem shadow_t-eintrag noch ein durch einen Doppelpunkt getrennter Eintrag vorhanden ist. Dabei handelt es sich um die Klassenzuweisung des zuvor angeführten Objekts, in diesem Fall ist das die Klasse file. Domänentransition Um nun vom aufrufenden Prozess des/der Benutzers/in mit der Domäne user_t in die passwd_t Domäne zu gelangen, muss eine Domänentransition stattfinden. Dabei handelt es sich um einen Wechsel von einer Domäne in eine andere. Domänentransitionen müssen ebenfalls explizit freigegeben werden. Um die Transition zu ermöglichen, wird die /usr/bin/passwd-datei mit einem neuen Typ passwd_exec_t versehen. Eine Transition für das /etc/shadow-datei Beispiel sieht wie in Listing 3 aus: allow user_t passwd_exec_t:file { getattr execute}; allow passwd_t passwd_exec_t:file entrypoint; allow user_t passwd_t:process transition; Listing 3: Definition einer Domänentransition (vgl. ebd. 2008, S. 148) Die erste Regel in Listing 3 erlaubt es dem/der Benutzer/in, (welcher/welche sich in der Domäne user_t befindet), Dateien vom Typ passwd_exec_t auszuführen. (Vgl. ebd. 2008, S. 148) 18

18 Die zweite Regel bestimmt den eigentlichen Wechsel. Entrypoint legt eine binäre Datei fest, welche für einen Wechsel in eine andere Domäne genutzt werden darf. Mit der Definition dieses Wechsels ist es nun für Binärdateien mit dem Typ passwd_exec_t möglich, in die Domäne passwd_t zu wechseln. Durch diese Definition ist es auch mit SetUID-Recht nicht mehr möglich, auf die geschützte Binärdatei zuzugreifen. (Vgl. ebd. 2008, S. 148) In der dritten und letzten Regel wird festgelegt, dass die Domäne user_t den Wechseln in die Domäne passwd_t durchführen darf. Damit ein Wechsel möglich ist, müssen alle drei Regeln angegeben werden, da jede nur einen Teil des Wechsels erlaubt. (Vgl. ebd. 2008, S. 148) Richtlinien SELinux basiert auf einer Richtlinien-Datei, welche als binäre Datei im /etc/selinux/<policy-name>/policy/-verzeichnis abgelegt wird. Um verschiedenen Ansprüchen an Sicherheit gerecht zu werden, gibt es mehrere Richtlinien, welche von den Linux-Distributoren mit ausgeliefert werden. Diese sind eine Strict, Targeted und Multi-Level-Security Richtlinie. Als SELinux erstmalig frei zur Verfügung stand, wurde nur die Strict Policy ausgeliefert. Bei dieser Richtlinie wird jeder Prozess in seiner eigenen Domäne abgehandelt. Durch die unterschiedlichen Domänen wird sichergestellt, dass jeder Prozess nur die benötigten Privilegien besitzt (Prinzip des Least Privilege). Dies ist der restriktivste Modus, welcher mit SELinux genutzt werden kann. Wird eine Applikation nicht ihrem Standard entsprechend eingesetzt, weicht dies von der Richtlinie ab und SELinux verbietet die Ausführung der Applikation. Da sehr viele Anwender/innen mit dieser rigorosen Einschränkung Probleme hatten, wurde die Targeted- Richtlinie entwickelt. (Vgl. Ralf Spenneberg 2008, S. 189) In der Targeted-Richtlinie wurde eine uneingeschränkte Domäne eingeführt. Diese Domäne ermöglicht es authentifizierten Benutzern/innen, das System ohne Einschränkungen durch SELinux zu benutzen. Der/die Root-Benutzer/in kann somit das System wie gewohnt administrieren. Nicht privilegierte Benutzer/innen werden ebenfalls mit einer unbeschränkten 19

19 Domäne versehen, mit der Einschränkung, dass sie beispielsweise nur Programme aus ihrem Heimatverzeichnis starten können. Alle exponierten Dienste wie beispielsweise Web- oder Datenbankservices werden in ihrer eigenen Domäne gestartet. Sollte ein solcher Dienst attackiert oder kompromittiert werden, ist es dem/der Angreifer/in nicht möglich, auf weitere Teile des Systems zuzugreifen, da dies von SELinux und der zugewiesenen Domäne verhindert wird. (Vgl. ebd., S. 189) Die MLS-Richtlinie kommt vor allem bei Trusted-Operating-Systemen zum Einsatz. Mit dieser Richtlinie ist es möglich, die Vertraulichkeit von Daten sicherzustellen. Die Daten werden dabei meist in hierarchischen Strukturen verwaltet und unterliegen beispielsweise mehreren Freigabestufen (Level). Mittels Type-Enforcement wäre dieses Konzept nur sehr schwer umzusetzen. Im Linux-Kernel gab es eine erste zur Laufzeit wechselbare MLS-Unterstützung. Bei dieser Policy erhalten alle Objekte auf dem System ein Label, welches entweder durch die Policy vorgegeben oder vom Kernel impliziert vergeben wird. Beispiele für die Beschriftung sind die /etc/shadow-datei und die /dev/mem-datei. (Vgl. 2008, S. 193). Zusätzlich zur MLS Richtlinie gibt es noch die Multi Category Security Richtlinie. Diese baut komplett auf MLS und den Type-Enforcement- Regeln auf. In einem MLS-System entscheidet das System, was für eine Sicherheitsstufe ein Objekt erhält. Im Gegensatz dazu, erhalten bei MCS alle Objekte dieselbe Sicherheitssensitivität (s0) und unterscheiden sich nur durch ihre Kategorie (c0-c2). Diese Kategorien können sofern diese über die entsprechenden Rechte verfügen von den Benutzern selbst verwaltet werden. (Vgl. Ralf Spenneberg 2008, S. 153) 20

20 2.2.5 Richtlinien entwickeln Möchte man ein Modul für eine Richtlinie entwickeln, können folgende drei Dateien erstellt werden: Interface-Datei: Diese Datei bietet eine Schnittstelle für andere Module an, so dass diese mit dem Modul interagieren können. Durch die Entkopplung von der Type-Enforcement-Datei wird sichergestellt, dass auch bestehende oder neu hinzugefügte Rollen oder Typen mit diesem Modul arbeiten können. Diese Datei ist für die Kompilierung optional. (Vgl. Andrew Gillies 2007) Type-Enforcement-Datei: Diese Datei beinhaltet die Typen und Regeln für Interaktionen mit dem Zielprogramm. Zur Erstellung eines Moduls muss diese Datei vorhanden sein. (Vgl. ebd. 2007) File-Context-Datei: Diese Datei spezifiziert, mit was für einem Kontext die Dateien versehen werden. Diese Datei ist für den Bau des Moduls optional. (Vgl. ebd. 2007) 21

21 2.3 Trusted Computing Dieses Unterkapitel ist keine vollständige Dokumentation über alle zur Verfügung stehenden Funktionalitäten des TPM oder der TCG Spezifikation. Es soll ein Überblick über Trusted Computing (TC), die TCG und das TPM gegeben werden, so dass die im weiteren Verlauf der Arbeit verwendeten Begriffe verstanden werden Trusted Computing System Ein Trusted Computing System (TCS) ist die Basis für Trusted Computing. Dabei besteht das TCS aus einer sicheren Rechnerplattform der Trusted Computing Platform (TCP) - und einem darauf aufzusetzenden Betriebssystem, dem Trusted Operating System (TOS). Abbildung 4: Aufbau des Trusted Computing Systems (Thomas Müller 2008, S. 20) Wie in Abbildung 4 zu sehen ist, stellt die TCP die Grundlage für ein solches System dar. Zu einer TCP gehören die folgenden Komponenten: Trusted Platform Module Core Root Of Trust For Measurement Trusted Software Stack (Vgl. ebd. 2008, S. 25) Diese drei Komponenten werden in den nächsten Abschnitten näher betrachtet. 22

22 2.3.2 TPM Müller gibt in seinem Buch eine sehr gute Definition über das TPM und dessen Verwendung bei Trusted Computing: Das TPM ist ein kryptographischer Prozessor, der fest mit der Hauptplatine (Mainboard) eines Computersystems verbunden ist. Es bietet unter anderem die Möglichkeit Prüfsummen über beliebige Daten zu erstellen und diese in einem geschützten Bereich zu hinterlegen. Viele der publizierten Anwendungsfälle von Trusted Computing basieren auf dieser Funktion des TPM. Sie verfolgen hierbei den Ansatz den Zustand eines Systems in Form von Prüfsummen über Hard- und Softwarekomponenten zu dokumentieren. (ebd. 2008, S. 16) Root of Trust Eine Trusted Computing Platform benötigt neben einem TPM noch eine weitere Komponente, diese wird als Core Root of Trust For Measurement (CRTM) bezeichnet. Die CRTM ist eine Erweiterung des BIOS und somit innerhalb der Firmware des Systems implementiert. Die CRTM stellt Instruktionen bereit, welche beim Start des Systems ausgeführt werden. Durch diese Instruktionen werden Prüfsummen von den am Start beteiligten Komponenten erstellt und in den sicheren Speicherbereichen des TPM abgelegt. Die Root of Trust wird auch oftmals als Vertrauensanker bezeichnet. (Vgl. Thomas Müller 2008, S. 25) Chain of Trust Die Vertrauenskette baut auf der Integrität und der Vertrauenswürdigkeit des Vertrauensankers auf. Um dies zu gewährleisten, muss zwischen jeder relevanten und vor allem sicherheitskritischen Komponente des Systems eine Beziehung zum Vertrauensanker bestehen. Wird das System gestartet, muss jede Komponente von der vorhergehenden geprüft werden, wobei die Prüfung durch die Erstellung einer Prüfsumme vorgenommen wird. Durch 23

23 diese Prüfungen wird die Vertrauenskette aufgebaut und Schritt für Schritt erweitert. In der nachfolgenden Abbildung ist eine vereinfachte Darstellung dieses Ablaufs zu sehen. Abbildung 5:Aufbau der Vertrauenskette (vgl. ebd. 2008, S. 53) In Abbildung 5 ist zu sehen, dass die ersten Messungen durch die CRTM durchgeführt werden. Die CRTM überprüft in Schritt 1 alle Komponenten, welche zur Trusted Computing Platform gehören. Nach dieser Messung wird die Kontrolle an den Lader des Betriebssystems (Bootloader) weitergegeben. Dieser Bootloader wurde um die TCP-Funktionalitäten erweitert und ist für die Weiterführung der Vertrauenskette zuständig. Nach der erfolgten Messung in Schritt 3, bei welcher vordefinierte Dateien geprüft werden, wird die Kontrolle an das Betriebssystem bzw. das Kernelsubsystem (Schritt 4) weitergereicht. Das Kernelsubsystem ist in Schritt 5 für die weiteren Messvorgänge innerhalb des Betriebssystems (Bibliotheken, ausführbare Dateien) zuständig und übergibt nach Beendigung dieser Messungen die Kontrolle an die Applikation. 24

24 Wie am linken Rand in Abbildung 5 ersichtlich ist, besteht die Vertrauenskette aus zwei Teilen. Static Chain of Trust Dieser Teil der Vertrauenskette ist durch Spezifikationen der TCG exakt vorgegeben. In dieser Kette sind alle Teilabschnitte bis zum Betriebssystem enthalten. Die Messungen sind unabhängig vom im Einsatz befindlichen Betriebssystem und erfolgen immer gleich. (Vgl. ebd. 2008, S. 53) Dynamic Chain of Trust Dieser Teil der Vertrauenskette wird durch das Trusted-OS erzeugt. Der verwendete Vertrauensanker ist die zuletzt von der TCP geprüfte Komponente. Diese Komponente stellt auch den Übergang von TCP zu Betriebssystem dar und ist in der Regel der Master Boot Record. Da es für die Dynamic Chain of Trust keine Spezifikation gibt, ist nicht vorgegeben, welche Komponenten des Betriebssystems überprüft werden müssen. (Vgl. ebd. 2008, S. 53) Trusted Software Stack Die Umsetzung des von der TCG spezifizierten Trusted Software Stacks (TSS) stellt verschiedenste Schnittstellen zur Kommunikation mit dem TPM bereit. Zusätzlich können Entwickler auf diesem Stack aufbauen und so eigene Funktionalitäten oder Erweiterungen entwickeln Integritätsmessung Müller beschreibt den Vorgang der Integritätsmessung wie folgt: Ein Vergleich der während des Startvorgangs und zur Laufzeit des Systems erzeugten Prüfsummen mit vorhandenen Referenzwerten soll eine Aussage über die Vertrauenswürdigkeit des Systems ermöglichen. Das Vertrauen in die korrekte Arbeitsweise eines Trusted-Computing-Systems basiert somit nicht notwendigerweise auf der formellen Verifikation aller Softwarekomponenten, sondern auf dem Vergleich des aktuellen 25

25 Systemzustands mit einem bekannten und als vertrauenswürdig eingestuften Zustand. (Ebd. 2008, S. 16) Wie von Müller beschrieben, handelt es sich bei der Integritätsmessung um eine Serie von Messungen. All diese SHA1-Hash Werte von beliebigen Datenblöcken (beispielsweise Betriebssystemkern, Treiber oder Applikationen) bilden den Zustand des Systems ab. Zur Speicherung der Messwerte stehen die Platform Configuration Registers (PCR) zur Verfügung. Diese Register besitzen eine Breite von 160 Bit und sind im flüchtigen Bereich des TPM zu finden. Bereits geschriebene Hashwerte können zur Laufzeit nicht mehr entfernt werden, erst bei einem Neustart des Systems werden die Register wieder gelöscht und müssen bei jedem Systemstart neu berechnet und abgelegt werden. (Vgl. ebd. 2008, S. 35) Beim Aktualisieren eines Registers wird der neu zu schreibende Hashwert mit dem bereits vorhandenen Wert im Register wie folgt verknüpft: PCR i New = Hash(PCR i Old value valueto add) PCR i stellt dabei das i-te Register dar. Die Operation wird als Verkettungsoperator bezeichnet. (Vgl. ebd. 2008, S. 37) Laut TCG Spezifikation müssen mindestens 24 dieser Register vorhanden sein (vgl. ebd. 2008, S. 36). In der nachfolgenden Tabelle werden die Zuordnungen der Register erläutert: 26

26 PCR Index PCR Verwendung 0 CRTM, BIOS und Host Platform Extensions 1 Host Platform Configuration 2 Option ROM Code 3 Option ROM Configuration and Data 4 IPL Code (meist der Master Boot Record) 5 IPL Configuration and Data 6 State Transition and Wake Events 7 Host Platform Manufacturer Control 8-15 Defined for use by the Static Operating System 16 Debug Defined for use by the Dynamic Operating System Tabelle 1: Zuordnung der Platform Configuration Registers (Vgl. ebd. 2008, S. 36) Während des Startvorgangs werden die Register 0-7 vom CRTM und dem BIOS gefüllt. Somit repräsentierten die Register 0-7 den Zustand des Systems vor dem Laden des Betriebssystems. In den Registern 8-15 sind Messwerte über die restlichen Komponenten, welche zum Systemstart gehören, abgelegt. (Vgl. ebd. 2008, S. 36) Schlüsselarten im TPM Innerhalb des TPM werden mehrere Schlüssel für verschiedenste kryptographische Aufgaben benötigt. Nachfolgend werden die wichtigsten Schlüssel vorgestellt. Endorsement Key Schon während der Fertigung des TPM wird der Endorsement Key (EK) erzeugt und im nichtflüchtigen Speicherbereich abgelegt. Dabei handelt es sich um ein RSA-Schlüsselpaar mit der Länge von 2048 Bit. Wurde der Schlüssel einmal eingerichtet, kann er nicht mehr gelöscht oder geändert werden. Um die Authentizität und Integrität dieses Schüssels sicherzustellen, verfügt der EK über ein EK-Zertifikat, welches vom Hersteller bei der 27

27 Erzeugung an den Schlüssel angeheftet wird. Der private Schlüssel kann lediglich vom TPM selbst gelesen werden. Selbst der Eigentümer des TPM ist nicht in der Lage, den Schlüssel auszulesen. Der EK ist ein einzigartiger Schlüssel und ermöglicht es, ein TPM zu identifizieren. Im Zusammenspiel mit den Platform Credentials können signierte Nachrichten zur Identifikation und Überprüfung der Vertrauenswürdigkeit des TPM erstellt werden. (Vgl. ebd. 2008, S. 34) Storage Root Key Der Storage Root Key (SRK) ist ebenfalls ein RSA-Schlüsselpaar mit der Länge von 2048 Bit. Erzeugt wird dieser Schlüssel während des Einrichtevorgangs durch den neuen Eigentümer. Nach der Erzeugung wird der SRK ebenfalls im nichtflüchtigen Speicher des TPM abgelegt. Laut Spezifikation sind der EK und der SRK die einzigen Schlüssel, welche zwingend im internen Speicher des TPM abgelegt werden müssen. Wie beim EK kann der private Teil des Schlüssels nur vom TPM ausgelesen werden. Der SRK wird dazu verwendet, um weitere kryptographische Schlüssel oder Daten sicher außerhalb des TPM abzuspeichern. (Vgl. ebd 2008, S. 34) Attestation Identity Key Wie die vorhergehenden beiden Schlüssel ist auch der Attestation Identity Key (AIK) ein RSA-Schlüsselpaar mit der Länge von 2048 Bit. Der AIK wird dazu verwendet, um die Vertrauenswürdigkeit des Systems über ein Netzwerk abzufragen (Remote Attestation). Dieser Vorgang verwendet den EK zum Signieren der Nachrichten. Um die durch diese Signierung eindeutige Identifizierung des TPM durch seinen eindeutigen EK zu verhindern, wurde der AIK eingeführt. Die Nachrichten werden mit dem AIK signiert, welcher nicht mit dem EK in Verbindung gebracht werden kann. Der AIK muss vorab durch eine vertrauenswürdige dritte Partei signiert werden. (Vgl. ebd. 2008, S. 35) In Kapitel 3 wird die Implementierung und Konfiguration der in diesem Kapitel beschriebenen Technologien beschrieben. Dabei werden, wo es nötig ist, weitere theoretische Details erläutert. 28

28 3 Implementierung In den nachfolgenden Unterkapiteln wird beschrieben, was bei der Implementierung und Konfiguration der beiden Hauptkomponenten (SELinux und des Trusted Platform Module) zu berücksichtigen ist und welche Schritte durchzuführen sind, um eine vertrauenswürdige Plattform zu schaffen. Zur Umsetzung wurden nur Open-Source-Produkte herangezogen, so dass nachfolgende Arbeiten auf dieser Ausarbeitung aufsetzen können und bei Bedarf der Source-Code analysiert werden kann. 3.1 Mandatory Access Control Per Definition ist ein/eine Administrator/in dazu da, ein System uneingeschränkt zu warten. Es stellt sich somit die Frage, wie und ob es überhaupt möglich ist, einen solchen Benutzer so weit einzuschränken, dass er/sie keine Berechtigungen mehr besitzt, sich Zugang zu den geschützten Bereichen oder Daten zu verschaffen. In den folgenden Abschnitten werden verschiedene Maßnahmen beschrieben, welche mit SELinux vorgenommen werden können, um diese Zielsetzung zu erreichen Abschaltung der Richtlinie verhindern Zur Analyse und Fehlersuche der SELinux-Richtlinie wurde zusätzlich ein permissive-modus eingeführt. In diesem Modus ist die Richtlinie zwar aktiv, allerdings wird keine Durchsetzung der Regeln durchgeführt. Dies ermöglicht es Administratoren/innen oder Entwickler/innen das SELinux-Log (/var/log/audit/audit.log) zur Analyse oder Anpassung der Richtline heranzuziehen, ohne dass dabei die Zugriffsmöglichkeiten eingeschränkt sind. Um Administratoren/innen daran zu hindern, den Modus von SELinux von enforcing auf permissive (und somit Zugriff auf alle Dateien zu erhalten) zu stellen, besteht die Möglichkeit, einen Kernel-Parameter zu setzen. Dieser Parameter bewirkt, dass nur noch nach einem Neustart des 29

29 Systems das Verhalten von SELinux geändert werden kann und nicht mehr zur Laufzeit. Der Kernel-Parameter heißt CONFIG_SECURITY_SELINUX_DEVELOP. Normalerweise müsste bei jeder Änderung eines Kernel-Parameters der Kernel neu kompiliert werden. Um dieses aufwändige Verfahren zu umgehen, wurde von den SELinux-Entwicklern/innen ein Flag implementiert, welches entsprechend gesetzt werden kann. Mit diesen Booleans ist er zur Laufzeit des Systems möglich, Kernelparameter zu setzen. Als Root Benutzer/in kann mit dem Aufruf aus Listing 4 das Flag gesetzt werden: # setsebool P secure_mode_policyload on Listing 4: Deaktivieren der Wechselmöglichkeit zwischen permissive und enforced Ein Wechsel vom deaktivierten Zustand wird nicht unterstützt. Voraussetzung ist, dass die Richtlinie geladen ist. (Vgl. Sven Vermeulen 2013, S. 27) Superuser beschränken Nachfolgend werden zwei Möglichkeiten beschrieben, wie ein privilegierter System-Benutzer eingeschränkt werden kann. Die Ergebnisse dieser Implementierungen werden in Kapitel 4 näher betrachtet. MLS(MCS)-Richtlinie mit Kategorien Wie in Abschnitt beschrieben, basiert die mls-richtline auf hierarchischen Strukturen, welche eine sehr feingranulare Rechtevergabe ermöglichen. Im ersten Schritt muss die mls-richtline installiert und aktiviert werden. Mit dem Kommando aus Listing 5 wird die Richtlinie installiert. # yum install selinux-policy-mls.noarch Listing 5: Installation der mls-richtlinie Nach erfolgreicher Installation folgt die Aktivierung der Richtlinie. Dazu muss in der SELinux-Konfigurationsdatei /etc/selinux/config die mls- Richtline eingetragen werden: SELINUXTYPE=mls 30

30 Eigene hierarchische Strukturen, welche die Rechteabstufungen repräsentieren, können in der Datei /etc/selinux/mls/setrans.conf angelegt werden. Diese Datei dient dazu, die von SELinux intern verwendeten Kategorien in ein für Menschen besser lesbares Format zu transformieren. Ein Beispiel für einen solchen Eintrag ist in Listing 6 zu sehen. s2=secret s2:c0=root-access s2:c1=no-root-access Listing 6: Sicherheitslevel in der setrans.conf S2 stellt dabei die Berechtigungsstufe dar. Die durch einen Doppelpunkt getrennten Kategorien ermöglichen eine Unterteilung dieser Stufe in verschiedene Kategorien. (Vgl. James Morris 2006) Nach der Einrichtung der Sicherheitsstufen und Kategorien können die zu schützenden Dateien oder auch ausführbaren Dateien mit einer neuen Kategorie versehen werden. Dies wird mit dem Kommando aus Listing 7 durchgeführt. # ls Z system_u:object_r:virt_image_t:s0 fedora20.qcow2 # chcat -- +No-Root-Access fedora20.qcow2 # ls Z system_u:object_r:virt_image_t:s0:no-root- Access fedora20.qcow2 Listing 7: Datei mit einer neuen Sicherheitsstufe versehen Die Datei, welche in Listing 7 editiert wurde, ist das Abbild einer virtuellen Maschine auf dem Host-System. Der/die Root-Benutzer/in erhält nun beim Start dieser Server-Instanz eine permission-denied Fehlermeldung. SELinux-Modul entwickeln Ziel dieser Variante ist es, ein eigenes Modul zu entwickeln, welches einen neuen Administrationsbenutzer soweit einschränkt, dass dieser nur noch die für ihn vorgesehenen Funktionen aufrufen kann. Zur Realisierung dieses Ansatzes wird ein eigener Benutzer iappl (inet-applikationsbenutzer) auf dem 31

31 System angelegt. Dieser Vorgang ist in Abschnitt beschrieben. Vorab muss jedoch das korrespondierende Modul erstellt werden. Ein SELinux-Modul besteht im Quellcode aus einer type-enforcement, file-context und einer interface-datei (iappl.te, iappl.fc, iappl.if). Beispielhafte Implementierungen, welche einen Login auf das System und das Öffnen von Netzwerk-Verbindungen erlauben, befinden sich auf dem dieser Arbeit beigefügten Datenträger. Damit das Modul kompiliert werden kann, muss das Entwicklungspaket selinux-policy-devel.noarch vorhanden sein. Die Installation des Entwicklungspakets erfolgt mit dem Kommando aus Listing 8. # yum install selinux-policy-devel.noarch Listing 8: Installation der mls-richtline Die Kompilierung muss im Verzeichnis, in welchem sich die Modul-Dateien befinden, mit dem Kommando aus Listing 9 durchgeführt werden. # make -f /usr/share/selinux/devel/makefile Listing 9: Kompilierung des SELinux-Moduls (vgl. o A 2013) Das Modul wird mit dem Kommando aus Listing 10 zur aktuellen Richtlinie hinzugefügt. # semodule i iappl.pp Listing 10: Laden des neuen Moduls Im nächsten Abschnitt wird das Anlegen des zu diesem Abschnitt gehörenden iappl-benutzers beschrieben SELinux-Benutzer anlegen Damit der virtuelle Server von einem/einer Benutzer/in gewartet werden kann, muss ein eigener SELinux-Benutzer und die entsprechende Zuordnung zur SELinux-Rolle angelegt werden. Die Funktionsweise dieser Zuordnungen ist in Kapitel näher beschrieben. 32

32 Zunächst muss der System-Benutzer mit dem Kommando aus Listing 11 angelegt werden. Dabei wird mit dem Z-Parameter schon der SELinux- Benutzer des System-Benutzers angegeben. # useradd d /home/iappl Z iappl_u iappl Listing 11: System-Benutzer für die Administration anlegen Im nächsten Schritt wird der bereits angesprochene SELinux-Benutzer mit dem Kommando aus Listing 12 angelegt. # semanage user -m -R "user_r" -r s0-s2:c0.c1 iappl_u Listing 12: SELinux-Benutzer anlegen Zu beachten ist, dass die richtigen Berechtigungsstufen (-r-parameter) mit den dazugehörenden Kategorien angegeben werden und die gewünschten SELinux-Rollen (-R-Parameter) ausgesucht werden. Als nächstes wird der Eintrag für die Login-Zuordnungstabelle angelegt. Dies wird mit dem Kommando aus Listing 13 durchgeführt. # semanage login -m -s iappl_u -r s0-s2:c0.c1 iappl Listing 13: Login-Zuordnung für SELinux erstellen Im Zuge dieser Arbeit wurde für die Virtualisierung die Virtualisierungs- Application Programming Interface (API) libvirt verwendet. Auf eine genaue Beschreibung der Funktionsweise von libvirt wird an dieser Stelle verzichtet, da dies nicht Teil dieser Arbeit ist. Es soll jedoch gezeigt werden, wie der zuvor angelegt iappl-benutzer die Möglichkeit erhält, auf seine virtuellen-instanzen zuzugreifen. Libvirt bedient sich zur Einschränkung von Rechten auf seinen Dämon dem Polkit-Werkzeug (vgl. Libvirt o. J.). Das Polkit-Werkzeug erlaubt es, nicht privilegierten Prozessen mit privilegierten Prozessen zu kommunizieren bzw. darauf zuzugreifen (vgl. ArchWiki 2014). Um dem iappl-benutzer Zugriff zu gewähren, muss im Verzeichnis /etc/polkit- 1/localauthority/50-local.d/ eine Konfigurationsdatei angelegt werden, welche den Inhalt aus Listing 14 beinhalten muss (vgl. Libvirt o. J.). 33

33 [libvirt Management Access] Identity=unix-user:iappl Action=org.libvirt.unix.manage ResultAny=yes ResultInactive=yes ResultActive=yes Listing 14: Management-Zugriff für den iappl-benutzer in libvirt anlegen (vgl. Libvirt o. J.) sysadm_secadm-modul deaktivieren Die SELinux-Richtlinie besteht aus mehreren Modulen, welche zur Laufzeit aktiviert und deaktiviert werden können. Im Februar 2012 wurde erstmals das Modul sysadm_secadm in die Referenzrichtlinie übernommen. Mit diesem Modul ist es möglich, Benutzer, welche unter dem sysadm_t-kontext arbeiten, soweit zu beschränken, dass diese nicht mehr auf sicherheitsrelevante Dateien zugreifen bzw. diese verändern können. (Vgl. Miroslav Grepl 2012) Da die targeted-richtlinie privilegierte System-Benutzer mit einem unconfined_t-kontext versieht, muss für die Verwendung dieses Moduls die mls-richtlinie verwendet werden. Mit dieser Richtlinie erhält der Root- Benutzer den Kontext sysadm_t. Dieser Kontext kann im Gegensatz zum unconfined_t-kontext in der Richtlinie eingeschränkt werden, was sich das sysadm_secadm-modul zunutze macht. Das sysadm_secadm-modul wird mit dem Befehl aus Listing 15 deaktiviert. # semodule -d sysadm_secadm Listing 15: Deaktivierung des sysadm_secadm-moduls Nach der Deaktivierung ist es dem/der Root-Benutzer/in nicht mehr möglich, SELinux-Kommandos, welche die Richtlinie verändern würden, auszuführen oder auf die Audit-Logdatei (/var/log/audit/audit.log) des Systems zuzugreifen. 34

34 3.2 Trusted Platform Computing Dieser Abschnitt beschreibt die Installation und Konfiguration der Komponenten, welche zur Schaffung der Trusted Computing Platform nötig sind. Applikationen OpenPTS tpm-tools Bibliotheken TrouSerS Linux-Kernel IMA TPM Treiber Boot TrustedGrub Hardware TPM Abbildung 6: Aufbau einer Trusted Computing Platform und deren Komponenten Der Aufbau der in Abbildung 6 dargestellten Schichten wird nachfolgend von unten nach oben beschrieben. Auf Grund der Tatsache, dass bei der Implementierung jedoch die TPM-Treiber, TrouSerS und tpm-tools schon vor deren Einreihung in den Schichten benötigt werden, ist deren Installation und Konfiguration bereits im Abschnitt TPM im BIOS und Kernel aktivieren beschrieben TPM im BIOS und Kernel aktivieren In diesem Abschnitt wird erläutert, wie das TPM auf dem Rechner aktiviert, im Kernel freigeschalten und anschließend in Besitz genommen wird. 35

35 TPM aktiveren Zu Beginn muss das TPM-Modul im Basic Input Output System (BIOS) des Rechners aktiviert werden. Die Option, das TPM zu aktivieren, hängt vom verwendeten Gerät und dem dazugehörigen BIOS ab. Nähere Informationen findet man im Handbuch des jeweiligen Geräteherstellers. TPM im Kernel aktivieren Ob das TPM-Modul im Kernel aktiviert ist, hängt von der zum Einsatz kommenden Linux-Distribution ab. Bei den von RedHat abstammenden Distributionen wie Fedora, RedHat Enterprise Linux und CentOS ist die Unterstützung für das TPM-Modul im Kernel bereits aktiviert. Mit dem folgenden Kommando kann überprüft werden, ob eine Unterstützung für das TPM in der Kernel-Konfiguration bereits vorhanden ist: # cat /usr/src/kernels/ fc20.x86_64/.config grep TPM CONFIG_HW_RANDOM_TPM=m CONFIG_TCG_TPM=m Listing 16: Überprüfung der TPM Unterstützung im Kernel (vgl. Dejan Lukan 2012) Wie in Listing 16 ersichtlich ist, wurde der Treiber für das TPM als nachladbares Modul konfiguriert (m steht dabei für Modul). Möchte man den Treiber fix im Kernel verankern, muss der Kernel neu gebaut werden. Wie ein Kernel neu gebaut wird, ist nicht Gegenstand dieser Arbeit und wird im Internet auf vielen Seiten genau beschrieben. Die Kategorie, in welcher das TPM im Kernel-Menü zu aktivieren ist, lautet: Device Drivers Character Devices TPM Hardware Support Um das TPM-Modul nutzen zu können, müssen noch drei Software-Pakete mit dem Kommando aus Listing 17 nachinstalliert werden. Alle Software- Pakete stammen vom Open Source-Projekt TrouSerS und beinhalten verschiedene Tools für das TPM. Das Paket TrouSerS ist eine freie Implementierung des TCG Software Stacks (vgl. TrouSerS Open Source Group o. J.) 36

36 # yum install tpm-tools tpm-tools-devel trousers Listing 17: Installation der TPM Software-Pakete Anschließend müssen die TPM-Treiber-Module geladen werden. Das Modul ist abhängig vom Hersteller des TPM-Chips. Zur Erstellung dieser Arbeit wurde ein TPM von Infineon verwendet. Mit den Kommandos aus Listing 18 werden die Kernelmodule geladen und deren erfolgreiche Ladung überprüft. # modprobe -a tpm tpm_tis tpm_infineon tpm_bios Überprüfung der Module mittels # lsmod grep tpm Listing 18: Laden der Treiber für das TPM Trousers stellt zur Kommunikation mit dem Treiber einen eigenen Dämon zur Verfügung. Der Trusted Computing Services Dämon (TCSD) muss vor der Verwendung des TPM gestartet werden. Unter Fedora wird der Dämon mit den Kommandos aus Listing 19 aktiviert und gestartet: # systemctl enable tcsd # systemctl start tcsd.service Listing 19: Aktivieren und Starten des TCSD Sobald der Dämon erfolgreich gestartet wurde, kann die Funktionalität des TPM mittels dem Kommando aus Listing 20 geprüft werden: # tpm_version TPM 1.2 Version Info: Chip Version: Spec Level: 2 Errata Revision: 2 TPM Vendor ID: IFX Vendor Specific data: b 00 TPM Version: Manufacturer Info: Initialisieren des TPM Listing 20: Ausgabe der TPM Version Bevor das TPM verwendet werden kann, muss es mit dem Befehl tpm_clear zurückgesetzt werden. Das heißt, dass das Modul von niemandem besessen wird und deaktiviert ist. Es ist nicht bei jedem Hardware-Hersteller möglich, dieses Kommando vom Betriebssystem aus 37

37 aufzurufen. Ist der Aufruf aus dem Betriebssystem nicht möglich, erhält man die Fehlermeldung aus Listing 21. # tpm_clear --force Tspi_TPM_ClearOwner failed: 0x d - layer=tpm, code=002d (45), Bad physical presence value Listing 21: Fehlermeldung beim Zurücksetzen des TPM Als nächstes muss das TPM mit dem Kommando aus Listing 22 in Besitz genommen werden, wobei das TPM mit einem Well-Known-Secret initalisiert wird (vgl. IBM Corporation o. J.). Dies wird in der weiteren Folge für die Remote Attestation in dieser Form benötigt. Normalerweise werden zwei Passwörter für den/die Besitzer/in und den SRK eingegeben. Da die Attestierungsprogramme jedoch einen Zugriff mit einem Well-Known-Secret durchführen, wird dieser Schritt nicht durchgeführt. # tpm_takeownership y -z Listing 22: Inbesitznahme des TPM Moduls (vgl. Dejan Lukan 2012) Erhält man beim Aufruf des Kommandos aus Listing 22 folgende Fehlermeldung: The TPM target command has been disabled, muss das Modul im BIOS zurückgesetzt werden. Um auf die TPM-Funktionalitäten zuzugreifen, sind noch zwei Kommandos wie in Listing 23 angegeben auszuführen. Mit diesen Kommandos wird das TPM freigegeben und aktiviert. # tpm_setenable Enter owner password: Disabled status: false # tpm_setactive Enter owner password: Persistent Deactivated Status: false Volatile Deactivated Status: false Listing 23: Freigeben und Aktivierung des TPM (vgl. Dejan Lukan 2012) Zur Kontrolle des TPM kann der Public Key des Endorsement Keys mit dem Kommando aus Listing 24 abgefragt werden: # tpm_getpubek 38

38 Listing 24: Abfrage des Endorsement Keys Im nächsten Abschnitt wird die Installation und Konfiguration des Trusted Grand Unified Bootloaders (GRUB) beschrieben TrustedGrub Um Trusted Boot bzw. einen vertrauenswürdigen Startvorgang zu realisieren, wurde der standardmäßige Grub Bootloader um Funktionalitäten erweitert, welche sich des TPM bedienen, um eine Integritätsprüfung durchzuführen. Die von der TCP spezifizierte Vertrauenskette wird somit nach dem CRTM und TCG-erweiterten BIOS fortgesetzt. Zusätzlich wird es dem/der Benutzer/in durch TrustedGrub ermöglicht, beliebige Dateien in die Integritätsmessung miteinfließen zu lassen. Multiboot Module Betriebssystem Kernel Zusätzliche Dateien vom Benutzer festgelegt Command list Grub Konfiguration Boot Loader Stage 2 Boot Loader Stage 1 Erweiterter Bootloader BIOS CRTM Erweiterte Hardware CPU Root Host wird gemessen von übergibt Kontrolle an Abbildung 7: Ablauf des Trusted Boot Vorgangs (vgl. Marcel Selhorst; Christian Stüble; Felix Teerkorn o. J., S. 10) 39

39 Die Messungen des Root Host aus Abbildung 7 werden in Kapitel beschrieben. Abbildung 7 zeigt, dass der Startvorgang mittels TrustedGrub in mehrere Schritte unterteilt worden ist. Stage1 stellt dabei den Code im Master Boot Record (MBR) dar, welcher die letzten protokollierten Instruktionen der TCP enthält. In Stage2 werden alle restlichen Instruktionen des Bootmanagers und die dazugehörende Konfiguration von Grub abgelegt. Zur Sicherstellung und Weiterführung der Vertrauenskette muss Stage1 den nachfolgenden Bereich Stage2 protokollieren und im entsprechenden PCR des TPM ablegen. Stage2 führt einige Messungen durch. Dabei wird zuerst die Grub-Konfigurationsdatei überprüft, welche einen Verweis auf das nachfolgend zu ladende Betriebssystem-Image enthält. Im Anschluss daran wird über dieses Image eine Prüfsumme (inklusive seiner Abhängigkeiten) erstellt. Zusätzlich bietet TrustedGrub noch die Möglichkeit, frei wählbare Dateien zur Vertrauenskette (mittels dem Schlüsselwort checkfile) hinzuzufügen. Diese Dateien werden ebenfalls vermessen und stellen das Ende der durch TrustedGrub erstellten Vertrauenskette dar. Im Anschluss daran wird die Kontrolle an das zu ladende Betriebssystem weitergereicht. (Vgl. Thomas Müller 2008, S. 94) Installation Zur Kompilierung von TrustedGrub müssen noch die Pakete, wie in Listing 25 angeführt, installiert werden. # yum install automake autoconf Listing 25: Von Trusted Grub benötigte Pakete nachinstallieren Im Anschluss kann die Kompilierung von TrustedGrub, wie in Listing 26 angegeben, durchgeführt werden: # tar xzf TrustedGRUB <ver >.tgz # cd TrustedGRUB #. /build_tgrub.sh v -f Listing 26: Kompilierung vonr TrustedGrub Verwendet man eine zu aktuelle Version von automake und autoconf, kann folgende Fehlermeldung erscheinen: pkglibdir is not a legitimate directory for `DATA`. 40

40 Um dieses Problem zu beheben, müssen die Schritte aus Listing 27 durchgeführt werden, um die neuesten Versionen korrekt zu unterstützen: # tar xfz TrustedGRUB src.tar.gz # cd TrustedGRUB # fgrep -rlz pkglib_data --include Makefile.am. \ xargs -0 sed -i s/pkglib_data/pkgdata_data/g # cd.. && mv TrustedGRUB src.tar.gz TrustedGRUB src.tar.gz.bak # tar cfz TrustedGRUB src.tar.gz TrustedGRUB Listing 27: Korrekturen für neueste Automake und Autoconf Versionen Zusätzlich können noch zwei Probleme auftreten. Das erste Problem stellen die fehlenden Testtreiber dar, welche mit folgender Fehlermeldung auf sich aufmerksam machen: parallel-tests: error: required file './test-driver' not found. Dieses Problem kann behoben werden, indem der Automake Aufruf im Installationsskript (build_tgrub.sh) wie in Listing 28 ersetzt wird: Alter Aufruf automake >& $VERBOSE Neuer Aufruf automake --add-missing >& $VERBOSE Listing 28: Ergänzen des Automake Aufrufs für fehlende Testtreiber Nachdem diese Probleme behoben wurden, kann es noch sein, dass das System, auf welchem TrustedGrub installiert werden soll, nicht über die notwendigen Entwicklungswerkzeuge verfügt. Zu beachten ist, dass bei 64Bit-Systemen noch zusätzliche Kompatibilitätswerkzeuge installiert werden müssen. Folgende Softwarepakete müssen installiert sein, damit die Kompilierung durchgeführt werden kann: compat-gcc-34.x86_64 gcc.x86_64 glibc.i686 glibc.x86_64 glibc-devel.i686 itext.x86_64 libgcc.i686 41

41 libgcc.x86_64 texinfo.x86_64 Sind alle Voraussetzungen erfüllt, kann die Kompilierung mit dem in Listing 26 angeführten Kommando durchgeführt werden. Im Anschluss an die Konfiguration müssen die Schritte aus Listing 29 als Root-Benutzer/in durchgeführt werden. # rm -rf /boot/grub2 # rm -rf /boot/grub # mkdir /boot/grub # cd <Pfad-zu>/TrustedGRUB-1.1.5/TrustedGRUB-1.1.5/ # make install # cp stage1/stage1 /boot/grub/ # cp stage2/stage2 /boot/grub/ # cd.. # cp default /boot/grub Konfiguration Listing 29: Abschließende Installation von TrustedGrub Nach erfolgreicher Installation muss der Bootloader konfiguriert werden. Die Konfiguration erfolgt wie in Listing 30 angegeben. # cd <Pfad-zu>/TrustedGRUB-1.1.5/TrustedGRUB #./grub/grub -no-floppy In der Grub Shell folgendes eingeben # root (hdx, y) # setup (hdx) # quit Listing 30: Installation von Grub im Dateisystem Zu beachten ist, dass Grub nicht die standardmäßige Auflistung der Festplatten und Partitionen aus Linux übernimmt. Es spielt keine Rolle, ob die Festplatte mittels hda oder sda angesprochen wird, innerhalb von Grub muss immer mit hd gearbeitet werden. Grub beginnt bei der Nummerierung nicht bei 1, wie bei Linux gewohnt, sondern startet auch dabei mit 0. Möchte man beispielsweise das Gerät /dev/sda2, auf welcher sich die /boot- Partition befindet, in Grub konfigurieren, sieht dies wie in Listing 31 angegeben aus. 42

42 root (hd0,1) setup (hd0) quit Listing 31: Grub Beispielkonfiguration mit der Partition sda2 Abschließend muss noch ein Eintrag im Grub-Menü angelegt werden. Es sollte darauf geachtet werden, keinerlei Fehler in diesen Menüeintrag einfließen zu lassen, da das System sonst nicht mehr gestartet werden kann. Vorab sollten alle Dateinamen aus dem /boot-verzeichnis kopiert werden, so dass eventuell auftretende Fehler in der Grub-Kommandozeile korrigiert werden können. Der Grub-Menüeintrag für Fedora 20 sieht wie in Listing 32 angegeben aus. 1. title Trustworthy Fedora root (hd0,1) 3. kernel /vmlinuz-<kernel-version> root=/dev/sda5 4. initrd /initramfs-<ramdisk-version>.img root=/dev/sda5 5. checkfile /grub/checkfile Listing 32: Grub Menüeintrag für Fedora In Zeile 1 wird der Titel des Menüeintrags angegeben. 2. Zeile 2 beinhaltet die /boot-partition (sofern eine eigene Partition verwendet wird), welche in Grub-Schreibweise anzugeben ist. 3. In Zeile 3 wird der Kernel mit der zu ladenden Root-Partition angegeben. Diese Root-Partition kann identisch mit der /boot-partition sein. Dies hängt von der Partitionierung des Systems ab und ist entscheidend für den erfolgreichen Bootvorgang! 4. Zeile 4 legt die zu ladende Ramdisk mit der zugehörigen Root-Partition fest. 5. Zeile 5 definiert eine Checkfile-Datei für TrustedGrub, welche im nächsten Abschnitt erläutert wird. TrustedGrub-Checkfile Bei dieser Datei handelt es sich um eine Konfigurationsdatei für zusätzlich zu prüfende Dateien. Wie in Abbildung 7 zu sehen ist, können zusätzliche Dateien in die Integritätsmessung miteinfließen. Diese Dateien werden über eben diese Konfigurationsdatei festgelegt. 43

43 Der Aufbau eines solchen Eintrags ist aus Listing 33 zu ersehen: Sha1 (hd?,?)/pfad/zur/datei Konkretes Beispiel: 3c d3e035a016f578d2fe80a82fd096a9 (hd0,1)/test Listing 33: Checkfile Syntax mit Beispiel Die erste Komponente ist die 40Bit lange SHA1-Prüfsumme der korrespondierenden Datei. Diese Prüfsumme kann mit dem unter Linux zur Verfügung stehenden Werkzeug sha1sum erstellt werden. Die zweite Komponente besteht aus der Festplattenreferenz und dem absoluten Pfad zur Datei selbst. Nach jeder Zeile muss das American Standard Code for Information Interchange (ASCII)-Zeichen für eine neue Zeile (\n) vorhanden sein, vor allem bei der letzten Zeile innerhalb der Datei ist darauf zu achten. Alle Prüfsummen dieser Dateien, welche mit dieser Methode überprüft werden, werden mittels Verkettungsoperator im PCR 13 abgelegt Integrity Measurement Architecture Die Integrity Measurement Architecture (IMA) ist eine Erweiterung für das Linux Kernel-Subsystem. Das Ziel von IMA ist es, den Integrity- Measurement-Prozess auf die Laufzeit des Betriebssystems auszuweiten. Voraussetzung dafür ist, dass ein vertrauenswürdiger Bootmanager zum Einsatz kommt. Da in diesem Fall TrustedGrub die zur IMA gehörenden Komponenten ebenfalls misst, ist die IMA selbst ebenso ein Glied in der Vertrauenskette und erweitert diese Kette somit auf das Betriebssystem. (Vgl. Thomas Müller 2008, S. 95) Die folgenden Daten werden zur Laufzeit und vor deren Ausführung gemessen und protokolliert: Ausführbare Instruktionen: Applikationen, Bibliotheken, Kernel-Module und Code, welcher ausgeführt wird, muss überprüft werden. 44

44 Strukturierte Daten: Darunter fallen alle Konfigurationsdateien, welche das Verhalten von Applikationen verändern können und somit Einfluss auf die Integrität des Systems haben. Unstrukturierte Daten: Darunter sind alle Daten von Applikationen zu verstehen, die von nicht vertrauenswürdigen Quellen stammen. Somit müssen diese gemessen und protokolliert werden. (Vgl. ebd. 2008, S. 96) Da es sich bei der Abbildung des Systemzustands zur Laufzeit um einen komplexen Prozess handelt, beschränkt sich die IMA jedoch auf die Erzeugung von Prüfsummen über die ausführbaren Instruktionen und strukturierten Daten. Um diese Prüfsummen zu erstellen, wird der Kernel um einen Systemaufruf erweitert, welcher auf den Linux Security Modules basiert. Dieser Systemaufruf wird immer aufgerufen, wenn ausführbare Kommandos von Applikationen oder dem Kernel geladen werden. Die dabei erzeugten Prüfsummen werden nicht direkt in den PCR des TPM abgelegt, sondern in einem eigens geführten Messprotokoll festgehalten. Durch dieses eigenständige Messprotokoll ist es möglich, jedes gemessene Objekt mit einer eigenen Prüfsumme, dem Namen des Objekts, zusätzlichen Informationen zur Prüfsumme und dem Zeitstempel der Messung zu versehen. Über das gesamte Messprotokoll wird eine neue Prüfsumme gebildet, welche in einem PCR des TPM abgelegt wird und somit für die Attestierung der Vertrauenswürdigkeit herangezogen werden kann. (Vgl. ebd. 2008, S. 96) Aktivierung der IMA In der für diese Arbeit verwendeten Fedora Distribution ist die IMA nicht standardmäßig im Kernel aktiviert. Dies bedeutet, dass zur Aktivierung der Funktionalität der Kernel neu gebaut werden muss. Zum Erstellen des Kernels sollte nicht der/die Root-Benutzer/in verwendet werden. Wie ein Kernel für Fedora neu gebaut wird, ist in zahlreichen Anleitungen im Internet zu erfahren, daher wird an dieser Stelle nicht näher darauf eingegangen. Als Hinweis sind in Listing 34 jedoch die Konfigurations-Parameter angeführt, welche IMA aktivieren. 45

45 CONFIG_IMA=y CONFIG_IMA_MEASURE_PCR_IDX=10 CONFIG_IMA_AUDIT=y CONFIG_IMA_LSM_RULES=y Listing 34: IMA Parameter für die Kernel Konfigurationsdatei Nach der erfolgreichen Kompilation und Installation des neuen Kernels, muss unbedingt darauf geachtet werden, dass noch das kernel-modulesextra Paket mit dem Kommando aus Listing 35 installiert wird, da ansonsten nicht mehr mit dem TPM kommuniziert werden kann. # yum install kernel-modules-extra.x86_64 Listing 35: Installation des kernel-modules-extra Pakets Wurde dieses Paket installiert, muss die Konfigurationsdatei /boot/grub/menu.lst mit dem neuen Kernel und der dazugehörenden Initramdisk versehen werden. Mit dem in Listing 36 angegeben Kommando kann nach einem Neustart des Systems überprüft werden, ob die IMA aktiv ist. # head -2 /sys/kernel/security/ima/ascii_runtime_measurements Ausgabe: a4224c5e4a27c6b1e258d423b9f389a774af9 ima-ng sha1:94b3520fee5ad5e68be d27fb3372a /init 10 caf6ca74be954ff fd90882f2e6a57e8a7 ima-ng sha1:f75bdebae086bb4a267cce317f4e7702f /usr/lib64/ld-2.18.so Listing 36: Ausgabe des IMA Betriebssystem-Messprotokolls mit Beispiel-Messwerten Die erste Spalte in Listing 36 beinhaltet das PCR, welches für die Aggregation aller Messwerte herangezogen wird. Die nächste Spalte beinhaltet den Template-Hashwert, welcher wie folgt erstellt wird: sha1 hash(daten-hash Länge, Daten-Hash, Pfadname-Länge, Pfadname) In der dritten Spalte ist vermerkt, welche Messvorlage zur Protokollierung verwendet wurde. Die vierte Spalte beinhaltet den eigentlichen Hashwert der geprüften Dateien. Dabei wird der Dateiinhalt zur Berechnung der 46

46 Prüfsumme herangezogen. In der letzten Spalte ist der Name der gemessenen Datei zu finden. (Vgl. David Safford; Dmitry Kasatkin; Serge Hallyn o. J.) Zusätzlich zu den Laufzeitmessungen werden auch die PCR 0 bis 7 in die Aggregation miteinbezogen. Diese Aggregation ist im IMA-Kontext als Boot- Aggregat zu finden und wird in der Berechnung der Prüfsumme für PCR 10 ebenfalls verwendet. Im nächsten Unterkapitel wird die Installation und Konfiguration der Verifizierungssoftware beschrieben, welche unter anderem auf der IMA aufsetzt Remote Attestation Unter Attestation versteht man den Vorgang einer Beweiserbringung. Im Zuge dieser Arbeit wird darunter die Beweiserbringung der Vertrauenswürdigkeit eines Systems gemeint. Eine solche Bescheinigung kann auf dem zu bewertenden System selbst ausgestellt werden. Voraussetzung dafür ist, dass ein sicherer Kommunikationskanal verwendet wird. Normalerweise findet eine solche Bescheinigung jedoch auf einem entfernten System statt. Da dieser Vorgang über ein öffentliches oder privates Netz durchgeführt werden kann, ist dafür Sorge zu tragen, dass die Authentizität und Integrität der zu überprüfenden Werte nicht beeinträchtigt wird. Zu den Werten, welche den Zustand des Systems beschreiben, gehören sämtliche Prozesse, welche sich im Hauptspeicher des Betriebssystems befinden, sowie alle Prozesse, welche zum Start des Systems beitragen. Dieser Zustand wird durch die Prüfsummen, welche sich in den Platform Configuration Register befinden, repräsentiert. (Vgl. Thomas Müller 2008, S. 55) Um die Integrität der übermittelten Werte sicherzustellen, wird bei der Übertragung das Konzept der Sicherheit auf Nachrichtenebene (Message Level Security) verwendet. Dabei werden vor dem Versenden die PCR-Werte digital signiert. 47

47 Abbildung 8: Ablauf der Remote Attestation (Vgl. ebd. 2008, S. 56) In Abbildung 8 ist der Ablauf dieses Vorgangs zu sehen. Die entfernte Instanz (Remote Service) versendet eine Challenge (normalerweise eine Zufallszahl) an das TPM. Das Trusted-OS muss dafür einen netzwerkfähigen Dienst zur Verfügung stellen. Zu dieser Zufallszahl werden noch die Indizes der zu signierenden PCR übergeben. Die neu erzeugte Response- Datenstruktur, welche aus der Challenge und den selektierten PCR Werten besteht, wird innerhalb der TPM mit einem Attestation Identity Key (AIK) signiert. Im Anschluss kann der Remote Service unter Verwendung des passenden Zertifikats die Identität des Systems und die Integrität der übermittelten Werte überprüfen. (Vgl. ebd. 2008, S. 56) Remote Attestation Service Zur Attestierung des Systems wird das Open-Source-Tool Open Platform Trust Services verwendet. Dabei handelt es sich um eine beispielhafte Referenzimplementierung der von der TCG veröffentlichten Platform Trust Services (PTS). (Vgl. Seiji Munetoh 2011a) Das TPM-Modul muss mit dem Well-Known-Secret aus Listing 22 initialisiert werden. Im Anschluss daran muss openpts mit dem Kommando aus Listing 37 installiert werden # yum install openpts.x86_64 Listing 37: Installation des Platform-Trust-Services PTS setzt auf den zur Static Chain of Trust gehörenden PCR auf. Zusätzlich werden noch die PCR-Werte der Dynamic Chain of Trust (PCR 10) in den 48

48 Attestierungsprozess miteinbezogen. Dabei bedient sich PTS den IMA- Dateien, welche fortlaufend geschriebenen werden und in den folgenden Dateien zu finden sind: Firmware Log-Datei: Diese Datei beinhaltet die PCR Werte der Firmware und wird vom TPM-Treiber aufbereitet. o /sys/kernel/security/tpm0/binary_bios_measurements Kernel Log-Datei: Diese Datei beinhaltet die Daten, welche für den Kernel PCR-Wert relevant sind (in der Regel PCR 10). o /sys/kernel/security/ima/binary_runtime_measuremen ts Diese beiden Log-Dateien können für die Integritätsbescheinigung entweder über den tcsd-dämon oder über openpts abgefragt werden. Die Konfiguration erfolgt in den jeweiligen Konfigurationsdateien im /etc- Verzeichnis. Möchte man den tcsd-dämon verwenden, müssen die Einstellungen aus Listing 38 in /etc/tcsd.conf eingetragen werden: firmware_log_file = /sys/kernel/security/tpm0/binary_bios_measurements firmware_pcrs = 0,1,2,3,4,5,6,7 kernel_log_file = /sys/kernel/security/ima/binary_runtime_measurements kernel_pcrs = 10 Listing 38: Einträge in der tcsd-konfigurationsdatei für die IMA Verwendung Die Zeilen zwei und vier in Listing 38 beschreiben die PCR, welche für die Firmware- und Kernel-Attestierung benötigt werden. Fast analog dazu können die Einstellungen in der ptsc.conf-datei vorgenommen werden: 49

49 iml.mode=securityfs bios.iml.file=/sys/kernel/security/tpm0/binary_bios_mea surements runtime.iml.file=/sys/kernel/security/ima/binary_runtim e_measurements pcrs.file=/sys/class/misc/tpm0/device/pcrs Listing 39: Konfiguration der ptsc.conf-datei für die IMA Verwendung In Listing 39 beschreibt die erste Zeile, dass zur Bescheinigung das securityfs herangezogen und somit direkt von ptsc aus darauf zugegriffen werden soll. Die nächsten beiden Zeilen beschreiben wieder die zu verwendenden IMA-Log-Dateien. Die letzte Zeile beinhaltet einen Verweis auf die PCR-Datei im /sys-dateisystem. Zusätzlich müssen noch die PCR- Register festgelegt werden, welche für die Attestierung verwendet werden sollen. Die Konfiguration ist in Listing 40 ersichtlich: # BIOS(SRTM) uses PCR0 to PCR7 rm.model.0.pcr.0=bios_pcr0.uml rm.model.0.pcr.1=bios_pcr1.uml rm.model.0.pcr.2=bios_pcr2.uml rm.model.0.pcr.3=bios_pcr3.uml rm.model.0.pcr.4=bios_pcr4.uml rm.model.0.pcr.5=bios_pcr5.uml rm.model.0.pcr.6=bios_pcr6.uml rm.model.0.pcr.7=bios_pcr7.uml # RM[1] OS (Linux-IMA with GRUB-IMA) rm.model.1.pcr.10=ima_pcr10.uml Listing 40: PCR Konfiguration in der ptsc.conf-datei (vgl. Seiji Munetoh 2011b, S. 7) Wurde die Konfiguration durchgeführt, muss ptsc mit dem Kommando aus Listing 41 initialisiert werden. 50

50 # ptsc -i Sign key location: SYSTEM Generate uuid: a7a821e8-dc11-11e3-b59a-3ca9f4983c8c Generate UUID (for RM): a8a8050e-dc11-11e3-b59a- 3ca9f4983c8c level 0 Reference Manifest : /var/lib/openpts//a8a8050e-dc11-11e3-b59a- 3ca9f4983c8c/rm0.xml ptsc has successfully initialized! Listing 41: Initialisieren des Platform-Trust-Services (vgl. Seiji Munetoh 2011b, S. 8) Sollte es während der Initialisierung eine Fehlermeldung mit dem Wert 0x2004 erscheinen, muss das TrouSerS-Softwarepaket neu kompiliert und installiert werden. (Vgl. Seiji Munetoh 2012) Um die Funktionsfähigkeit von ptsc zu testen, kann das Kommando aus Listing 42 verwendet werden. # ptsc -t selftest - OK Listing 42: Selbsttest des Platform-Trust-Services durchführen (vgl. Seiji Munetoh 2011b, S. 8) Zur Absicherung des Attestierungs-Vorgangs wird das SSH-Protokoll verwendet. Um die Attestierung zu ermöglichen, muss ein entsprechender RSA-Schlüssel erzeugt und auf dem zu überprüfenden System hinterlegt werden. In Listing 43 sind die Kommandos für diese beiden Vorgänge ersichtlich. # ssh-keygen t rsa # ssh-copy-id <user>@<hostname> Listing 43: Erzeugung eines RSA-Schlüssels und Hinterlegung auf dem System (vgl. Seiji Munetoh 2011b, S. 8) Der Service kann nun mit dem Kommando aus Listing 44 gestartet werden. Dass System kann somit überprüft werden. # ptsc -s Listing 44: Starten des ptsc-services Im nächsten Schritt muss das verifizierende System installiert werden. Beide Systeme das zu prüfende und das überprüfende verwenden dasselbe 51

51 Softwarepaket. Die Installation erfolgt daher identisch. Dazu müssen die Kommandos aus Listing 37 und Listing 43 ausgeführt werden. Als nächstes wird der sogenannte Sammler aufgesetzt. Dies wird mit dem Kommando aus Listing 45 getan. # openpts -i localhost -f -V Target: localhost Manifest UUID: ec8c6aa6-dc31-11e3-9de8-3ca9f4983c8c Manifest[0]: /root/.openpts/ebac6366-dc31-11e3-9de8-3ca9f4983c8c//ec8c6aa6-dc31-11e3-9de8-3ca9f4983c8c/rm0.xml Collector UUID: ebac6366-dc31-11e3-9de8-3ca9f4983c8c Configuration: /root/.openpts/ebac6366-dc31-11e3-9de8-3ca9f4983c8c/target.conf Validation policy: /root/.openpts/ebac6366-dc31-11e3-9de8-3ca9f4983c8c/policy.conf Listing 45: Initialisierung des Sammlers (vgl. Seiji Munetoh 2011b, S. 8) Wie in Listing 45 ersichtlich ist, werden einige Konfigurationsdateien in einem versteckten Verzeichnis des verwendeten Benutzers angelegt. Diese werden beim Attestierungsvorgang benötigt. Die Attestierung des Systems wird mit dem Kommando aus Listing 46 durchgeführt: # openpts -v localhost integrity: invalid 0 [POLICY-L009] tpm.quote.pcr.10 is 41cg84BOdvS++dQRZcCDBXUkMeo=, not Y1FVE3J0CSZIxLO32tjWwe7VDM8= Listing 46: Remote-Attestierung durchführen und deren Ergebnis (vgl. Seiji Munetoh 2011b, S. 9) Wie in Listing 46 ersichtlich ist, war die Verifizierung des Systems nicht erfolgreich, da der Wert in PCR 10 nicht mit dem zu vergleichenden Wert übereinstimmt. Möchte man bei dem Verifizierungsvorgang sicherstellen, dass auch während des Vorgangs aktualisierte Messwerte miteinbezogen werden, muss die Option u an das Kommando aus Listing 46 angehängt werden. 52

52 Im nachfolgenden Kapitel werden die Ergebnisse der in diesem Kapitel implementierten Werkzeuge näher beschrieben. Dabei wird auf Erweiterungsmöglichkeiten und Probleme eingegangen, welche während oder beim Zusammensetzen der Komponenten auftraten. 53

53 4 Ergebnisse In diesem Kapitel werden die Ergebnisse der Implementierung diskutiert, sowie weitere im Zuge dieser Arbeit durchgeführte Tests besprochen. Es sollen hier auch Möglichkeiten diskutiert werden, welche zuerst sehr vielversprechend erschienen, sich schlussendlich aber als nicht umsetzbar herausstellten. Die Ergebnisse werden sequentiell wie in Kapitel 3 diskutiert. 4.1 Mandatory Access Control Ein MAC-Framework ist ein sehr mächtiges Werkzeug, mit welchem sehr tiefe Einschnitte in das Berechtigungssystem des Betriebssystems gemacht werden können. Da dieses Framework sehr viele Möglichkeiten anbietet, kann man auch mehrere Ansätze auswählen, um das Ziel der Superuser- Beschränkung zu erreichen. Alle Ansätze, welche während der Erstellung dieser Arbeit getestet wurden, haben nicht zu einer zufriedenstellenden Umsetzung mittels SELinux geführt MLS-Richtline mit Kategorien Das in Abschnitt 3.1 (MLS-Richtlinie) beschriebene Verfahren funktioniert insofern, dass der Superuser in seinen Möglichkeiten zwar sehr stark eingeschränkt wird, es dem neu angelegten iappl-benutzer jedoch nicht möglich ist, vom Superuser angelegte Dateien mit einem neuen Kontext zu versehen. Dieses Verhalten ist auf die SELinux-Constraints zurückzuführen. Diese Einschränkungen könnten mit einem eigens entwickelten Richtlinien-Modul behoben werden. In diesem Modul müsste der Eintrag aus Listing 47 eingetragen werden. 54

54 gen_require(' type iappl_t; ') allow $1 iappl_t:dir_file_class_set getattr; Listing 47: Inhalt des Richtlinien-Moduls um Dateiklassen zu setzen Um dieses Modul verwenden zu können, muss vorab noch ein Typ iappl_t angelegt werden, welcher auch dem iappl-benutzer zugewiesen werden muss. Dies kann mit dem Eintrag in Listing 48 in einer iappl.te-datei getan werden. type iappl_t; Listing 48: SELinux-Typ für den iappl-benutzer festlegen Dieser Vorgang müsste bei jedem neu hinzukommendem Benutzer wiederholt werden. Im Zusammenspiel mit den beiden Optionen aus Abschnitt Abschaltung der Richtlinie verhindern und sysadm_secadm-modul deaktivieren ermöglicht diese Variante eine starke Einschränkung des Superusers. Vorteile Die Vorteile dieser Variante sind: Die Implementierung kann mit einem geringen Aufwand durchgeführt werden (verglichen mit der Entwicklung eines eigenen Moduls). Es müssen keine bestehenden Richtlinien-Dateien angepasst werden. Kategorien können noch für weitere Einschränkungen (beispielsweise Dateien) verwendet werden. Nachteile Sicherheitsstufen können ohne Adaptierung der Richtlinie nicht gesetzt werden Es benötigt für neue Benutzer immer eine Erweiterung des SELinux- Moduls 55

55 4.1.2 SELinux-Modul entwickeln Ein weiterer Ansatz, um den Superuser einzuschränken, war, ein selbst angelegtes SELinux-Modul zu verwenden. Dabei wird der zusätzlich angelegte Benutzer mit den benötigten Rechten versehen und erhält somit nur Zugriff auf die System-Objekte, die er wirklich benötigt. Als Quelle diente dabei die Referenz-Richtlinie von SELinux. Die Rechte wurden mittels Trialand-Error Verfahren zum Richtlinien-Modul hinzugefügt, was während der Implementierung zu einem sehr instabilen System führte. Der Grund dafür war, dass der Security-context sysadm_t eingeschränkt wurde, welcher für sehr viele Vorgänge auf dem System benötigt wird. Diese Vorgehensweise ermöglichte es jedoch, einen Einblick in die Komplexität der Referenz-Richtlinie zu erhalten. Der Bau eines zweiten Administrations-Moduls stellt einen enormen Aufwand dar, weshalb nur eine beispielhafte Umsetzung des Moduls durchgeführt wurde. Die Schwierigkeiten hinter der Erstellung eines solchen Moduls sind die sehr vielfältigen Aufgaben, welche ein Administrator zu erfüllen hat. Zusätzlich zu den sehr vielen Aufgaben, kommt noch die hohe Anzahl an Hypervisors hinzu, welche von dem Modul unterstützt werden sollten. Vorteile Sehr starke Einschränkung des/der Benutzers/in möglich Nachteile Intensive Einarbeitung in die Richtlinien-Entwicklung notwendig. Hohe Komplexität der Aufgabe. Hoher Zeitaufwand Role Based Access Control SELinux bietet die Möglichkeit, Zugriffe an Hand der SELinux-Rolle des Benutzers zu steuern. Diese Variante baut auf einem SELinux-Modul auf, welches die Rolle entsprechend einschränkt. Sind dieses Modul und die dazugehörende Rolle verfügbar, kann mit einem sehr geringen Aufwand ein eingeschränkter Benutzer angelegt werden. Für die Einschränkung eines 56

56 Virtualisierungs-Administrators wird somit ein Modul, wie in Abschnitt beschrieben, benötigt. (Vgl. Dominick Grift 2009) Zur Erlangung der nötigen Superuser-Rechte, könnte der Linux Befehl sudo verwendet werden. Mit diesem Programm ist es möglich, Prozesse mit den Rechten eines anderen Benutzers (beispielsweise dem Systembenutzer Root) zu starten. Ein solcher Eintrag in der sudo-konfigurationsdatei würde wie in Listing 49 angegeben aussehen. iappl ALL=(ALL) TYPE=virtadm_t ROLE=virtadm_r ALL Listing 49: Eintrag für einen Rollenwechsel in der sudo-konfigurationsdatei Vorteile Einfache Umsetzung, wenn ein Modul vorhanden ist Nachteile Kein Rollen-Modul vorhanden, somit dieselben Nachteile wie in Abschnitt Virtualisierung Ein Problem, welches während der Implementierung erkannt wurde, ist, dass die Virtualisierungs-Bibliothek libvirt während des Starts einer virtuellen Instanz immer neue MLS-Stufen und MCS-Kategorien (beispielsweise s0:c34,c44) an die Festplatten-Abbild-Datei anhängt. Dieses Verhalten ist auf die SELinux svirt-schutzmechanismen für Quick-Emulator (QEMU) zurückzuführen. Dieses Verhalten dient dazu, die einzelnen QEMU-Prozesse voneinander zu schützen, da jeder Prozess eine eindeutige Kategorie erhält und somit der Zugriff unter den QEMU-Prozessen nicht möglich ist. (Vgl. Libvirt o. J.). Man sieht somit, dass zur Abschottung der Prozesse schon Schutzmechanismen implementiert worden sind. Da die Virtualisierungsschicht erst zum Schluss der Arbeit betrachtet wurde, ist dieses Problem zu spät erkannt worden. Eventuell wäre es mit dem Einsatz eines anderen Hypervisors (beispielsweise XEN) möglich, dieses Verhalten zu umgehen. 57

57 4.3 TrustedGrub Eine zusätzliche Absicherung gegen eine unbemerkte Änderung der SELinux-Richtlinie kann erreicht werden, in dem die SELinux-Richtlinien- Datei zur checkfile-konfiguration von TrustedGrub hinzugefügt wird. Ist dies der Fall, wird dies in die Erzeugung des entsprechenden PCR Wertes miteinfließen. Es würde somit auf jeden Fall bemerkt werden, ob die Richtlinie von einem/einer Benutzer/in absichtlich oder unabsichtlich verändert wurde. TrustedGrub basiert auf der Grub Version 1, welche noch keine neuen UEFI- Systeme unterstützt (vgl. Olga Chen 2014). Die Implementierung selbst konnte nur mittels einer Emulation eines BIOS durchgeführt werden. Eine Portierung von TrustedGrub auf die Grub Version 2 wäre die Lösung für dieses Problem. Um dies durchzuführen, benötigt es jedoch ein hohes Maß an Wissen über Grub und die Programmiersprache Assembler. Für den Einsatz in Unternehmen, welche zumeist Standard-Industrieserver einsetzen, ist dieser Umstand ein K.O-Kriterium. Auf einem solchen System sind sehr viele Treiber und Komponenten im Einsatz, was zumeist zu einer Vereinheitlichung der Hardware und Konfiguration der Server führt. Muss nun eine gewisse Anzahl der Server mit einer anderen Konfiguration betrieben werden, wird das betreuende Administrations-Team dies vermutlich versuchen zu verhindern. 4.4 Integrity Measurement Architecture Bei der standardmäßig mitausgelieferten IMA-Richtlinie ima_tcb (Integrity Measurement Architecture_Trusted-Computing-Base) werden die folgenden Objekte geprüft: Alle Programme, welche ausgeführt werden Alle Dateien, welche lesend für den/die Benutzer/in mit der User-Id 0 geöffnet wurden (vgl. David Safford; Dmitry Kasatkin; Serge Hallyn o. J.) Dateien, welche mit dem Systemcall mmap (Memory-Map) eine Zuweisung in den virtuellen Adressraum erhalten (Michael Kerrisk 2014; vgl. David Safford; Dmitry Kasatkin; Serge Hallyn o. J.) 58

58 Während der Implementierung war es mit der ima_tcb-richtlinie nicht möglich, einen stabilen Wert in PCR 10 zu erhalten. Um zu überprüfen, welche Dateien dieses Verhalten hervorrufen, wurden zwei Messungen durchgeführt und die Datei aus Listing 50 als Ursache für den Unterschied identifiziert: /var/lib/plymouth/boot-duration Listing 50: Datei, welche den IMA PCR-Wert beeinflusst In dieser Datei ist die Dauer des Startvorgangs des Systems abgespeichert. Es besteht die Möglichkeit, eine eigene IMA-Richtlinie zu erstellen. Dazu muss im Verzeichnis /etc/ima eine Datei mit dem Namen ima-policy angelegt werden. In dieser Datei können die zu überprüfenden Dateisysteme und verschiedene SELinux-Kontexte angegeben werden, welche von den Messungen ausgeschlossen werden sollen. Es besteht außerdem die Möglichkeit, zwischen Lese und Schreiboperationen zu unterscheiden. (Vgl. ebd. o. J.) Die in Listing 50 angegebene Datei besitzt den SELinux-Kontext plymouthd_var_lib_t. Es wurde versucht, diesen Kontext zu einer Ausnahme hinzuzufügen, um einen konstanten PCR-Wert zu erhalten. Diese Maßnahme hat jedoch keine Veränderung am Verhalten des sich verändernden PCR-Wertes herbeigeführt. Ein Problem, welches nur in einem realen Betrieb festzustellen ist, ist die enorme Last, welche IMA auf dem System erzeugt. Wie in Tabelle 2 ersichtlich ist, dauert der Startvorgang mit der ima_tcb-richtlinie mehr als doppelt so lange. Die Messvorgänge der IMA wirken sich nicht nur auf den Startvorgang aus, sondern auch auf die Laufzeitperformance des gesamten Systems. Dieses Verhalten kommt daher, dass in der ima_tcb-richtlinie alle Lese- und Schreibvorgänge des Root-Benutzers gemessen werden. Da sehr viele Dämonen mit dem Root-Kontext betrieben werden, werden ständig Messungen durchgeführt.in einem produktiven Umfeld muss dieser Umstand auf jeden Fall beachtet werden. 59

59 Richtlinie Aktivierte ima_tcb-richtlinie (Root-Schreib- und Lesevorgänge) Angepasste Richtlinie (nur Root-Schreibvorgänge) Dauer in Sekunden 58,36 26,87 Tabelle 2: Dauer des Startvorgangs (Login in das System möglich) mit aktiver IMA 4.5 Remote Attestation Bei der standardmäßig aktivierten IMA-Richtlinie ima_tcb werden alle Dateien, welche von dem/der Root-Benutzer/in geöffnet werden, einer Protokollierung unterzogen. Dies bedeutet, dass jede neu geöffnete Datei die Prüfsumme in PCR 10 verändert. Dies führt bei der Integritätsbescheinigung wiederum dazu, dass die Plattform als nicht vertrauenswürdig angesehen wird. Die Frage, welche sich dabei stellt, ist, wie reagiert man auf eine solche Änderung der PCR-Werte? Es gibt dabei die Möglichkeit, wie eben beschrieben, dass die IMA-basierenden Werte den PCR 10 verändern. Was ist aber, wenn ein/eine Benutzer/in die SELinux-Richtlinie verändert und dies eine Änderung ist, welche nicht die zu schützenden virtuellen Instanzen betrifft? Die zum Aufbau der Vertrauenskette benötigten Regeln besagen, dass jegliche Änderung zu einem Verlust der Integrität führt. Was sich durch diesen Verlust der Integrität jedoch nicht genau ableiten lässt, ist, was die Ursache für den sich geänderten PCR-Wert ist. Es benötigt somit immer eine manuelle Kontrolle und Freigabe eines solchen Systems, so dass es wieder in einen vertrauenswürdigen bzw. produktiven Zustand übergehen kann. Im anschließenden Kapitel werden verschiedene ähnliche Technologien kurz vorgestellt. Die meisten dieser Technologien wurden erst gegen Ende der Ausarbeitung gefunden und fanden somit keine Berücksichtigung während der Implementierungsphase. Dem Leser soll durch die Auflistung dieser Technologien jedoch ein breiteres Spektrum an Möglichkeiten vorgestellt werden. 60

60 5 Verwandte Technologien Die in dieser Arbeit angewendeten Technologien, welche in Kapitel 3 zur Implementierung verwendet wurden, sind in der zur Erstellung dieser Arbeit herangezogenen Literatur erwähnt worden. Dies war der Grund, wieso diese Werkzeuge für die Implementierung verwendet wurden. Während der Erstellung wurden auch andere Technologien gefunden, welche zur Erreichung der Zielsetzung verwendet werden hätten können. In diesem Abschnitt soll eine Übersicht über diese Technologien und Werkzeuge gegeben werden, so dass es dem Leser möglich ist, auch auf diesen aufzusetzen. Die Unterpunkte dieses Kapitels sind von der Hardware- hin zur Softwareebene beschrieben. 5.1 Intel Trusted Execution Technology Mit Intels Trusted Execution Technology (TXT) erhält man in jedem Server, welcher über diesen Chip verfügt, automatisch eine geschützte Wurzel des Vertrauens. Dies offeriert ein hohes Maß an Flexibilität und Erweiterbarkeit wenn es um die Messung der einzelnen Komponenten des Systems geht. Dabei können Komponenten wie das BIOS, der Betriebssystem-Lader oder aber auch Virtual Machine Manager (VMM) gemessen werden. Zusätzlich bietet die Wurzel auch noch die Möglichkeit an, Messergebnisse mit hinterlegten Ergebnissen zu vergleichen.(vgl. James Greene 2012, S. 3) Die TXT wurde im Jahr 2007 der Öffentlichkeit vorgestellt. Den Einzug in den Serverbereich schaffte sie jedoch erst im Jahr (Vgl. ebd. 2012, S. 3) Funktionsweise Intels TXT basiert auf der Erstellung eines Measured Launch Environment (MLE). Mit MLE ist es möglich, alle kritischen Elemente der Startkonfiguration gegen eine vertrauenswürdige Quelle prüfen zu lassen. Jede Komponente, welche am Startvorgang beteiligt ist, wird mit einem kryptographisch eindeutigen Bezeichner versehen. Im Anschluss daran überprüft ein in der Hardware verankerter Mechanismus diese Bezeichner. Stimmen diese 61

61 Bezeichner nicht überein, wird die Ausführung dieser Komponente geblockt. Diese in der Hardware verankerte Lösung stellt die Grundlage für eine sichere Plattform gegen softwarebasierte Angriffe dar. (Vgl. ebd. 2012, S. 3) Zusätzlich bietet die TXT noch folgende Möglichkeiten an: Verified Launch: Eine auf Hardware basierende Vertrauenskette, welche es erlaubt, mit MLE in einen vertrauenswürdigen Status zu gelangen. Änderungen an der MLE können durch kryptographische Messungen entdeckt werden. (Vgl. ebd. 2012, S. 3) Lauch Control Policy (LCP): Ist ein Verifikations-Mechanismus, mit welchem festgestellt wird, ob die Plattformkonfiguration den hinterlegten Richtlinien entspricht. (Vgl. ebd. 2012, S. 3) Secret Protection: Hardware-unterstützte Mechanismen, welche beispielsweise Daten nach einem unvorschriftsmäßigen Herunterfahren des MLE schützen und somit ein Ausspähen der Daten im Hauptspeicher verhindern. (Vgl. ebd. 2012, S. 3) Attestation: Bietet die Möglichkeit an, Bescheinigungen über das System auszustellen. Dabei kann dies lokal oder durch einen entfernten Host durchgeführt werden. (Vgl. ebd. 2012, S. 3) 62

62 Der Ablauf des Startvorgangs und Schutz des VMM mit den wichtigsten Entscheidungspunkten ist in Abbildung 9 dargestellt. Abbildung 9: Abschottung eines virtuellen Servers mit Intels TXT (Vgl. ebd. 2012, S. 4) Im ersten Schritt werden die Werte, welche zur Überprüfung herangezogen werden, im TPM abgelegt. In Schritt 2 werden die Werte aus dem TPM mit den zur Laufzeit erzeugten Werten überprüft. In Punkt 3 wird das Ergebnis der Überprüfung ausgewertet und entsprechende Aktionen eingeleitet. Befindet sich das System in einem vertrauenswürdigen Zustand, wird in Schritt 4 der VMM überprüft. Erst nach einer positiven Verifizierung in Schritt 5 wird mit der Ausführung der virtuellen Server begonnen. (Vgl. ebd. 2012, S. 4) 63

63 5.1.2 Wurzel des Vertrauens mit TXT Es gibt, wie in Abschnitt beschrieben, zwei unterschiedliche Methoden, eine Wurzel des Vertrauens in einem System zu erstellen. Die Static Root of Trust for Measurements (SRTM) startet bei einem Reset-Event der Plattform und geht wie beschrieben über ein nicht veränderbares BIOS und den Betriebssystem-Loader bis hin zum Betriebssystem selbst. Der Vorteil liegt dabei in der Einfachheit der SRTM. Die Schwäche der SRTM ist dabei der Umstand, dass zum Aufbau der Vertrauenskette sehr viele Komponenten herangezogen werden müssen. Dies bedeutet, dass sobald sich eine Komponente der Kette ändert nachdem der vertrauenswürdige Zustand hergestellt wurde das gesamte System neu vermessen bzw. versiegelt werden muss. (Vgl. ebd. 2012, S. 6) Die zweite Methode, um eine Wurzel des Vertrauens zu erstellen, ist die Dynamic Root of Trust for Measurement (DRTM). DRTM führt zu einer wesentlich kleineren Trusted Computing Base. Die DRTM wird erst aktiv, wenn ein sicherheitsrelevanter Event auftritt. Dies kann beispielsweise der Start eines Hypervisors sein. Tritt dieser Event ein, initialisiert das System die Root of Trust for Measurement. Dabei werden Komponenten welche vor dem DRTM-Event liefen, nicht in die Trusted Computing Base übernommen und können somit nicht mehr ausgeführt werden. (Vgl. ebd. 2012, S. 6) Der Ansatz von DRTM würde jedoch Komponenten wie das BIOS ausschließen. Um dieses Problem zu beheben, hat Intel bei der Umsetzung von TXT Merkmale aus beiden Ansätzen übernommen und implementiert, so dass ein sicheres System zur Verfügung steht. (Vgl. ebd. 2012, S. 7) 5.2 Trusted Boot Trusted Boot (TBOOT) ist ein Open-Source pre-kernel/vmm Modul welches auf Intels TXT aufsetzt und somit in der Lage ist, den Start des Betriebssystems und des VMM zu messen und verifizieren. (Vgl. Jimmy Wei u. a. 2014) 64

64 Trusted Boot bietet folgende Funktionalitäten an: Measured Launch: Findet TBOOT beim Start einen TXT-fähigen Prozessor, wird versucht, ein Measured Launch durchzuführen. Wird kein TXT-fähiger Prozessor gefunden, findet ein Start ohne TXT statt. (Vgl. ebd. 2014) Abrüsten der Messwerte: Geht das System in einen Schlafzustand, werden die entsprechenden Messwerte korrekt zerstört. (Vgl. ebd. 2014) Daten im Hauptspeicher schützen: TBOOT unterstützt Intels Mechanismus zum Schutz der Daten im Hauptspeicher. Dieser Fall tritt ein, wenn das System nicht normal heruntergefahren wurde. (Vgl. ebd. 2014) Schutz des TXT-Speichers: TXT reserviert gewisse Regionen im Speicher für sich und verwendet zusätzlich noch Memory Mapped I/O. TBOOT schützt diese Speicherbereiche vor jeglichem Zugriff durch den Hypervisor. (Vgl. ebd. 2014) Verified Launch: TBOOT erweitert die Verifikation des Systems vom Measured Launch Environment bis hin zum verwendeten Virtual Machine Monitor. Dazu werden Richtlinien verwendet, welche ähnlich der Launch Control Policy sind und werden ebenfalls im nichtflüchtigen Speicher des TPM abgelegt. (Vgl. ebd. 2014) TBOOT stellt somit mehr als nur eine Alternative zu TrustedGrub dar. Auf eine Implementierung von TBOOT musste aus zeitlichen Gründen verzichtet werden. Der einzige Nachteil von TBOOT ist, dass es nur mit Intels TXT lauffähig ist. 5.3 OpenAttestation Bei Open Attestation handelt es sich um ein Software Development Kit (SDK), welches Cloud-Anbietern die Möglichkeit bietet, die Integrität von Systemen zu überprüfen. Es handelt sich dabei um kein fertiges Produkt, sondern um ein SDK, welches von Software-Entwicklern in ihr eigenes Produkt eingebettet werden kann. Das SDK fügt einer existierenden Infrastruktur keine zusätzlichen Sicherheitsmechanismen hinzu, sondern 65

65 setzt auf einer bereits bestehenden Infrastruktur auf. (Vgl. Gang Wei 2012b, S. 5) OpenAttestation setzt auf Intels TXT und TBOOT auf, um eine Verifizierung des Systems vorzunehmen. (Vgl. Gang Wei 2013) Auf eine Implementierung wurde wie bei Intels TXT und TBOOT aus zeitlichen Gründen verzichtet. Es wird nachfolgend jedoch ein Überblick über die Architektur und die Möglichkeiten von OpenAttestation gegeben Architektur Abbildung 10: Architektur von OpenAttestation (vgl. Gang Wei 2012a, S. 3) Wie in Abbildung 10 zu sehen ist, bietet OpenAttestation die Möglichkeit, Systeme über einen zentralen Service zu verifizieren. Dabei muss auf den zu verifizierenden Systemen ein Agent installiert werden, über welchen der zentrale Service (der Appraiser) die benötigten Daten für die Verifizierung erhält. Der installierte Agent bedient sich dabei durch den TrouSerS TSS der PCR des TPM und liefert diese Werte über das Attestation-Protokoll an den Service zurück. (Vgl. ebd. 2012a, S. 4) Der Attestation-Service bietet eine zentrale Schnittstelle an, über welche die Cloud-Management-Software welche nicht Teil von OpenAttestation ist - den Status der einzelnen Systeme abfragen kann. Zusätzlich beinhaltet der Attestation-Service noch eine Privacy Certificate Authority. Diese wird 66

66 benötigt, um die AIK der zu verifizierenden Systeme zu zertifizieren. (Vgl. ebd. 2012a, S. 4) Komponenten Die Komponenten von OpenAttestation sind in Abbildung 11 dargestellt. Abbildung 11: Komponenten von OpenAttestation (Vgl. ebd. 2012a, S. 6) Nachfolgend werden die einzelnen Komponenten aus Abbildung 11 beschrieben: Attestation Service API HTTPS: Dieser Service stellt eine Restful API bereit, mit welcher die Hosts verwaltet und deren Integritätsstatus abgefragt werden kann. (Vgl. ebd. 2012a, S. 6) WhiteList Service API HTTPS: Mit dieser Schnittstelle können das MLE, die zugehörigen MLE-Attribute, gültige Gesamt-Messwerte und PCR-Werte hinterlegt werden. (Vgl. ebd. 2012a, S. 6) Historical Integrity Reporting Portal: Über dieses Portal können bereits gespeicherte Reports von einzelnen Systemen angesehen werden. 67