Trusted Boot und Mandatory Access Control: Vertrauenswürdige Ver

Transcription

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 (1210249001)
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
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 OpenSource 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 OpenSource Softwarepaket Trusted-Boot und ein Attestierungswerkzeug namens
OpenAttestation. Abschließend wird ein Fazit gezogen und ein Ausblick über
die weitere Verwendung der Werkzeuge gegeben.
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.
Inhaltsverzeichnis
1
2
Einleitung ................................................................................................ 7
1.1
Nutzen für den Auftraggeber ............................................................. 9
1.2
Ziele dieser Arbeit ............................................................................. 9
Technologieübersicht ............................................................................ 11
2.1
Testsystem ..................................................................................... 11
2.2
Mandatory Access Control .............................................................. 12
2.2.1
SELinux .................................................................................... 13
2.2.2
Linux Security Modules ............................................................ 14
2.2.3
Funktionsweise......................................................................... 15
2.2.4
Richtlinien ................................................................................. 19
2.2.5
Richtlinien entwickeln ............................................................... 21
2.3
3
Trusted Computing ......................................................................... 22
2.3.1
Trusted Computing System ...................................................... 22
2.3.2
TPM.......................................................................................... 23
2.3.3
Root of Trust ............................................................................ 23
2.3.4
Chain of Trust ........................................................................... 23
2.3.5
Trusted Software Stack ............................................................ 25
2.3.6
Integritätsmessung ................................................................... 25
2.3.7
Schlüsselarten im TPM ............................................................ 27
Implementierung ................................................................................... 29
3.1
3.1.1
Abschaltung der Richtlinie verhindern ...................................... 29
3.1.2
Superuser beschränken ........................................................... 30
3.1.3
SELinux-Benutzer anlegen ....................................................... 32
3.1.4
sysadm_secadm-Modul deaktivieren ....................................... 34
3.2
Trusted Platform Computing ........................................................... 35
3.2.1
TPM im BIOS und Kernel aktivieren ......................................... 35
4
3.2.2
TrustedGrub ............................................................................. 39
3.2.3
Integrity Measurement Architecture.......................................... 44
3.2.4
Remote Attestation ................................................................... 47
Ergebnisse ............................................................................................ 54
4.1
5
4.1.1
MLS-Richtline mit Kategorien ................................................... 54
4.1.2
SELinux-Modul entwickeln ....................................................... 56
4.1.3
Role Based Access Control ...................................................... 56
4.2
Virtualisierung ................................................................................. 57
4.3
TrustedGrub.................................................................................... 58
4.4
Integrity Measurement Architecture ................................................ 58
4.5
Remote Attestation ......................................................................... 60
Verwandte Technologien ...................................................................... 61
5.1
6
Intel Trusted Execution Technology ................................................ 61
5.1.1
Funktionsweise......................................................................... 61
5.1.2
Wurzel des Vertrauens mit TXT ............................................... 64
5.2
Trusted Boot ................................................................................... 64
5.3
OpenAttestation .............................................................................. 65
5.3.1
Architektur ................................................................................ 66
5.3.2
Komponenten ........................................................................... 67
5.3.3
Anwendungsfall ........................................................................ 68
Zusammenfassung und Ausblick .......................................................... 69
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-ÖsterreichSchweiz (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
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 RootSystem-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 HostSystem Anbieters so weit wie möglich eingeschränkt werden.
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
ü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
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
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-------. 1 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 rootBenutzer- 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
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.
2.2.1 SELinux
Bei SELinux handelt es sich um eine konkrete Umsetzung der MACStrategie. 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
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
Kernel space
Fehlerüberprüfung
Keine Fehler
Zugriff verweigert
Daten suchen
Zugriff verweigert
Fehler
System call
DAC Überprüfungen
DAC Ok
LSM Hook
Aufruf Ok?
LSM retourniert ja/nein
Linux Security Module
(Beispiel SELinux)
LSM Ok
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
sondern verlässt sich auf Implementierungen, welche auf der LSMFunktionalität aufsetzen. (Vgl. Sven Vermeulen 2013, S. 10)
2.2.3 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 SecurityContext.
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 LinuxBenutzer/innen denselben SELinux-Benutzer verwenden. (Vgl. ebd
2008, S. 141)
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 MLSRichtlinie 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
2.2.4 erläutert wird. (Vgl. ebd. 2008, S. 152)
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 SetUIDRecht 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
# 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
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)
2.2.4 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 TargetedRichtlinie 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
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 2.6.12 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-EnforcementRegeln 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
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
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.
2.3.1 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
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)
2.3.3 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)
2.3.4 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
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
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)
2.3.5 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.
2.3.6 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
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:
𝑃𝐶𝑅𝑖 𝑁𝑒𝑤 = 𝐻𝑎𝑠ℎ(𝑃𝐶𝑅𝑖 𝑂𝑙𝑑 𝑣𝑎𝑙𝑢𝑒 || 𝑣𝑎𝑙𝑢𝑒𝑡𝑜 𝑎𝑑𝑑)
𝑃𝐶𝑅𝑖 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
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
17-23
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)
2.3.7 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
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
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.
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.
3.1.1 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
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)
3.1.2 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 2.2.4 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 mlsRichtline eingetragen werden: SELINUXTYPE=mls
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-RootAccess 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
System angelegt. Dieser Vorgang ist in Abschnitt 3.1.3 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.
3.1.3 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 2.2.3 näher beschrieben.
32
Zunächst muss der System-Benutzer mit dem Kommando aus Listing 11
angelegt werden. Dabei wird mit dem –Z-Parameter schon der SELinuxBenutzer 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 VirtualisierungsApplication 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/polkit1/localauthority/50-local.d/
eine Konfigurationsdatei angelegt werden,
welche den Inhalt aus Listing 14 beinhalten muss (vgl. Libvirt o. J.).
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.)
3.1.4 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 RootBenutzer 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
3.2 Trusted Platform Computing
Dieser Abschnitt beschreibt die Installation und Konfiguration der
Komponenten, welche zur Schaffung der Trusted Computing Platform nötig
sind.
OpenPTS
Applikationen
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.
3.2.1 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
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/3.13.9-200.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 SoftwarePakete 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
# 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:
1.2.3.19
Spec Level:
2
Errata Revision:
2
TPM Vendor ID:
IFX
Vendor Specific data: 0313000b 00
TPM Version:
01010000
Manufacturer Info:
49465800
Listing 20: Ausgabe der TPM Version
Initialisieren des TPM
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
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: 0x0000002d - 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
Listing 24: Abfrage des Endorsement Keys
Im nächsten Abschnitt wird die Installation und Konfiguration des Trusted
Grand Unified Bootloaders (GRUB) beschrieben.
3.2.2 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
vom Benutzer
festgelegt
Zusätzliche Dateien
Betriebssystem Kernel
Command list
Grub
Konfiguration
Boot Loader Stage 2
Erweiterter
Bootloader
Boot Loader Stage 1
BIOS
Erweiterte
Hardware
CRTM
CPU
wird gemessen
von
Root Host
übergibt Kontrolle
an
Abbildung 7: Ablauf des Trusted Boot Vorgangs (vgl. Marcel Selhorst; Christian Stüble; Felix
Teerkorn o. J., S. 10)
39
Die Messungen des Root Host aus Abbildung 7 werden in Kapitel 2.3.4
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-1.1.5
# . /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
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-1.1.5.src.tar.gz
# cd TrustedGRUB-1.1.5
# fgrep -rlZ pkglib_DATA --include Makefile.am . \
| xargs -0 sed -i ’s/pkglib_DATA/pkgdata_DATA/g’
# cd .. && mv TrustedGRUB-1.1.5.src.tar.gz TrustedGRUB1.1.5.src.tar.gz.bak
# tar cfz TrustedGRUB-1.1.5.src.tar.gz TrustedGRUB1.1.5
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

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
Listing 29: Abschließende Installation von TrustedGrub
Konfiguration
Nach erfolgreicher Installation muss der Bootloader konfiguriert werden. Die
Konfiguration erfolgt wie in Listing 30 angegeben.
# cd <Pfad-zu>/TrustedGRUB-1.1.5/TrustedGRUB-1.1.5
# ./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 /bootPartition befindet, in Grub konfigurieren, sieht dies wie in Listing 31
angegeben aus.
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 20
2. 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 20
1. 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
Der Aufbau eines solchen Eintrags ist aus Listing 33 zu ersehen:
Sha1 (hd?,?)/Pfad/Zur/Datei
Konkretes Beispiel:
3c06943433d3e035a016f578d2fe80a82fd096a9 (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.
3.2.3 Integrity Measurement Architecture
Die Integrity Measurement Architecture (IMA) ist eine Erweiterung für das
Linux Kernel-Subsystem. Das Ziel von IMA ist es, den IntegrityMeasurement-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

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
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:
10 517a4224c5e4a27c6b1e258d423b9f389a774af9 ima-ng
sha1:94b3520fee5ad5e68be46882294221d27fb3372a /init
10 caf6ca74be954ff3380077fd90882f2e6a57e8a7 ima-ng
sha1:f75bdebae086bb4a267cce317f4e7702f1125406
/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
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 BootAggregat 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.
3.2.4 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
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 ResponseDatenstruktur, 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
Attestierungsprozess miteinbezogen. Dabei bedient sich PTS den IMADateien, 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 /etcVerzeichnis.
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
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 PCRRegister 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[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
# ptsc -i
Sign key location: SYSTEM
Generate uuid: a7a821e8-dc11-11e3-b59a-3ca9f4983c8c
Generate UUID (for RM): a8a8050e-dc11-11e3-b59a3ca9f4983c8c
level 0 Reference Manifest :
/var/lib/openpts//a8a8050e-dc11-11e3-b59a3ca9f4983c8c/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
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-9de83ca9f4983c8c//ec8c6aa6-dc31-11e3-9de83ca9f4983c8c/rm0.xml
Collector UUID: ebac6366-dc31-11e3-9de8-3ca9f4983c8c
Configuration: /root/.openpts/ebac6366-dc31-11e3-9de83ca9f4983c8c/target.conf
Validation policy: /root/.openpts/ebac6366-dc31-11e39de8-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
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
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.
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 SuperuserBeschrä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.
4.1.1 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
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 SELinuxModuls
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.
4.1.3 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
Virtualisierungs-Administrators wird somit ein Modul, wie in Abschnitt 4.1.2
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 4.1.2.
4.2 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
4.3 TrustedGrub
Eine zusätzliche Absicherung gegen eine unbemerkte Änderung der
SELinux-Richtlinie kann erreicht werden, in dem die SELinux-RichtlinienDatei 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 UEFISysteme 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
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
Richtlinie
Dauer in Sekunden
Aktivierte ima_tcb-Richtlinie
58,36
(Root-Schreib- und Lesevorgänge)
Angepasste Richtlinie
26,87
(nur Root-Schreibvorgänge)
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
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 2010. (Vgl. ebd. 2012, S. 3)
5.1.1 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
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
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
5.1.2 Wurzel des Vertrauens mit TXT
Es gibt, wie in Abschnitt 2.3.4 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
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
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.
5.3.1 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
benötigt, um die AIK der zu verifizierenden Systeme zu zertifizieren. (Vgl.
ebd. 2012a, S. 4)
5.3.2 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

Host Agent API HTTPS: Stellt die Schnittstelle für den Host Agent zur
Verfügung, an welchen die Reports des Systems übermittelt werden.
(Vgl. ebd. 2012a, S. 6)

Privacy Certificate Authority: Verifiziert den Endorsement Key des
TPM und stellt ein Zertifikat (Endorsement Key Certificate) aus. Mit
diesem Zertifikat kann der Host ein Zertifikat für den Attestation
Identification Key beantragen. (Vgl. ebd. 2012a, S. 6)

Appraiser: Verifiziert die Messungen der Hosts, welche mittels des
AIK-Zertifikats signiert wurden.
5.3.3 Anwendungsfall
Abschließend wird noch ein typischer Anwendungsfall für OpenAttestation
beschrieben werden.
Abbildung 12: Anwendungsfall für OpenAttestation (Vgl. ebd. 2012a, S. 5)
In Abbildung 12 ist zu sehen, dass ein Benutzer eine Aufgabe auf einem
System ausführen möchte, sofern sich dieses in einem vertrauenswürdigen
Zustand befindet. In Schritt 1 wird eine Anfrage an den Attestation-Service
übermittelt, welcher die Anfrage in Schritt 2 an das entsprechende
Zielsystem (konkret an den Host-Agent) weiterleitet. Das Zielsystem
retourniert seinen Report in Schritt 3 an den Attestation-Service. Der
Appraiser validiert den erhaltenen Report mit seiner Datenbank und meldet in
Schritt 5 das Ergebnis an den Benutzer zurück. (Vgl. ebd. 2012a, S. 5)
68
6 Zusammenfassung und Ausblick
Die Ziele, welche in Abschnitt 1.2 beschrieben worden sind, wurden nicht zur
Gänze erreicht. Die Zielsetzung, Dateien vor dem Zugriff durch Superuser zu
schützen, wurde insofern erreicht, dass eine Möglichkeit gefunden wurde,
dies mittels SELinux umzusetzen. Wünschenswert wäre es, dass diese
Einschränkung besser mit der Virtualisierungsschicht zusammenarbeitet. Da
die für die Implementierung verwendete Hardware erst mit einiger
Verspätung eingetroffen ist, wurde hier zu Beginn der Ausarbeitung der
Fehler gemacht, zu wenig auf die Virtualisierungsschicht zu achten. Zu
Beginn fanden die Tests selbst in einer virtuellen Umgebung statt und dies
führte dazu, dass eben jener Virtualisierungsschicht zu wenig
Aufmerksamkeit zuteil kam. SELinux ist von sich aus nicht dazu entworfen
worden, Superuser auf einem System einzuschränken. Wie gezeigt wurde,
ist es dennoch möglich, dieses Ziel zu erreichen. Wünschenswert wäre es
allerdings, dass die Referenz-Richtlinie selbst schon Möglichkeiten dafür
anbietet. Gerade im unternehmerischen Umfeld von inet-logistics wäre es
zukünftig wünschenswert, ein Framework zur Verfügung zu haben, welche
diese Möglichkeiten bietet. Im Bereich von Zertifizierungen (ISO 27001- ITSecurity) wird sehr oft nach Möglichkeiten gefragt, wie nicht
vertrauenswürdige Benutzer eingeschränkt werden können. Somit wäre auch
eine kommerzielle Nutzung einer solchen Umsetzung durchaus vorstellbar.
Das Ziel, die Vertrauenswürdigkeit des Systems zu bescheinigen, wurde
grundsätzlich umgesetzt. Was nicht funktioniert, ist, dass der PCR Wert 10,
welche von der IMA erstellt wird, konstant bleibt. Interessant ist, dass die
mitausgelieferte ima_tcb-Richtlinie Regeln enthält, welche einen nicht
konstanten PCR Wert erzeugen. Diese Richtlinie wurde eigentlich dafür
entwickelt, eine Trusted Computing Base zu schaffen und liefert trotzdem
keine konstanten Werte für eine Attestierung des Systems.
Im Vergleich zu der während der Implementierung verwendeten Software
muss klar gesagt werden, dass die in Abschnitt 5 beschriebenen alternativen
Technologien zukunftssicherer sind. Dies betrifft vor allem TrustedGrub,
welches derzeit nicht weiterentwickelt wird. Voraussetzung für die
Implementierung dieser Alternativen ist jedoch die Verfügbarkeit von Intels
69
TXT auf dem verwendeten System, was eine gewisse Einschränkung
darstellt, die sich im Umfeld von Unternehmen jedoch nicht als allzu kritisch
erweisen sollte.
Trusted Computing wird in absehbarer Zukunft mit Sicherheit an Bedeutung
gewinnen, da sich nicht nur durch die immer häufiger auftretenden Skandale
rund um Datensicherheit mehr und mehr Unternehmen, aber auch
Privatpersonen, nach einer Verifizierung ihrer Systeme streben. Im Umfeld
von Unternehmen lassen sich durchaus einige Anwendungsfälle für Remote
Attestation finden. Eine hohe Akzeptanz dieses Verfahrens im privaten
Umfeld ist – nach heutigem Stand - auszuschließen, da der dafür
aufzubringende Aufwand für die meisten Privatpersonen, insbesondere
Laien, meist nicht praktikabel ist.
Bei der Abschottung des Systems mittels SELinux muss noch angemerkt
werden, dass ein/eine Root-Benutzer/in stets die Möglichkeit hat, sich
Zugang zum System zu verschaffen. Dies kann beispielsweise durch die
Neuinstallation der SELinux-Richtlinie erreicht werden. Dieser Umstand
würde zwar bemerkt werden, jedoch bleibt die Fragen offen, was für
Änderungen in der Zwischenzeit durchgeführt worden sind.
Bei der Umsetzung von Trusted Computing muss beachtet werden, dass
sehr viele Software-Anbieter, speziell Betriebssystemdistributoren, strenge
Richtlinien besitzen, wie ein System auszusehen hat, so dass ein gültiger
Supportvertrag abgeschlossen werden kann. Beispielsweise ist es meistens
nicht erlaubt, einen selbst kompilierten Kernel zu verwenden. Damit IMA zur
Verfügung steht, muss bekanntlich der Kernel neu kompiliert werden, was in
diesem Falle zu einem Verlust der Unterstützung durch den Support-Anbieter
führen würde.
70
Literaturverzeichnis
Andrew Gillies (2007): Notes on SElinux: policies and modules |
equivocation. Online im Internet: http://equivocation.org/node/13 (Zugriff am:
02.06.2014).
ArchWiki (2014): Polkit - ArchWiki. Online im Internet:
https://wiki.archlinux.org/index.php/Polkit (Zugriff am: 30.05.2014).
David Safford; Dmitry Kasatkin; Serge Hallyn (o. J.): Integrity Measurement
Architecture (IMA) / Wiki / Home. Online im Internet:
http://sourceforge.net/p/linux-ima/wiki/Home/#ima-policy-examples (Zugriff
am: 19.05.2014).
Dejan Lukan (2012): Linux TPM Encryption: Enabling TPM in BIOS and
Kernel - InfoSec Institute. Online im Internet:
http://resources.infosecinstitute.com/linux-tpm-encryption/ (Zugriff am:
14.04.2014).
Dominick Grift (2009): SELinux Mandatory Access Control: SELinux
Lockdown Part Six: Customized SELinux Roles. Online im Internet:
http://selinux-mac.blogspot.co.at/2009/06/selinux-lockdown-part-sixcustomized.html (Zugriff am: 30.05.2014).
Gang Wei (2013): Features/OpenAttestation - FedoraProject. Online im
Internet: http://fedoraproject.org/wiki/Features/OpenAttestation (Zugriff am:
05.06.2014).
Gang Wei (2012a): OpenAttestation SDK Overview o. J.
Gang Wei (2012b): OpenAttestation SDK ReadMe o. J.
Hewlett-Packard Development Company, L.P (2012): HP EliteBook 8570p
Notebook PC computer model and HP ProBook 6570b Notebook PC
Maintenance and Service Guide o. J.
IBM Corporation (o. J.): Hilfe - AIX 7.1 Information Center. Online im Internet:
http://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ib
m.aix.cmds%2Fdoc%2Faixcmds5%2Ftpm_changeauth.htm (Zugriff am:
19.05.2014).
James Greene (2012): Intel® Trusted Execution Technology o. J.
James Morris (2006): james_morris: Getting Started with Multi-Category
Security (MCS). Online im Internet: http://jamesmorris.livejournal.com/8228.html (Zugriff am: 28.05.2014).
Jimmy Wei u. a. (2014): Trusted Boot Readme o. J.
Libvirt (o. J.): libvirt: Connection authentication. Online im Internet:
http://libvirt.org/auth.html (Zugriff am: 30.05.2014a).
Libvirt (o. J.): libvirt: KVM/QEMU hypervisor driver. Online im Internet:
http://libvirt.org/drvqemu.html#securityselinux (Zugriff am: 30.05.2014b).
Marcel Selhorst; Christian Stüble; Felix Teerkorn (o. J.): TSS Studie Sirrix
AG security technologieso. J.
Michael Kerrisk (2014): mmap(2) - Linux manual page. Online im Internet:
http://man7.org/linux/man-pages/man2/mmap.2.html (Zugriff am:
19.05.2014).
Miroslav Grepl (2012): [selinux-policy] - Add new sysadm_secadm.pp module
* contains secadm definition for sysadm_t - Move user_mail_. Online im
Internet: https://lists.fedoraproject.org/pipermail/scm-commits/2012February/731590.html (Zugriff am: 26.05.2014).
o A (2013): SELinux/Tutorials/Creating your own policy module file - Gentoo
Wiki. Online im Internet:
http://wiki.gentoo.org/wiki/SELinux/Tutorials/Creating_your_own_policy_mod
ule_file (Zugriff am: 26.05.2014).
Olga Chen (2014): TrustedGRUB / Mailing Lists. Online im Internet:
http://sourceforge.net/p/trustedgrub/mailman/message/32263961/ (Zugriff
am: 02.06.2014).
Ralf Spenneberg (2008): SELinux & AppArmor: Mandatory Access Control
für Linux einsetzen und verwalten. Pearson Deutschland GmbH.
Red Hat Inc. (2014): Red Hat | The Fedora Project: Open source
evolved. Online im Internet:
http://www.redhat.com/resourcelibrary/articles/the-fedora-project-opensource-evolved (Zugriff am: 16.04.2014).
Seiji Munetoh (2012): Fedora 17 Quick setup guide · openpts/openpts Wiki ·
GitHub. Online im Internet: https://github.com/openpts/openpts/wiki/Fedora17-Quick-setup-guide (Zugriff am: 21.05.2014).
Seiji Munetoh (2011a): Open Platform Trust Services (OpenPTS). Online im
Internet: http://openpts.sourceforge.jp/ (Zugriff am: 14.05.2014).
Seiji Munetoh (2011b): Open Platform Trust Services (OpenPTS) User’s
Guide o. J.
Sven Vermeulen (2013): SELinux System Administration. Birmingham: Packt
Publishing Ltd.
Thomas Müller (2008): Trusted Computing Systeme. Berlin: Springer-Verlag.
Thomas Wolfe (2012): Secure Linux: Part 1. SELinux – history of its
development, architecture and operating principles. Online im Internet:
http://www.ibm.com/developerworks/linux/library/l-secure-linuxru/index.html?ca=dat (Zugriff am: 16.04.2014).
TrouSerS Open Source Group (o. J.): TrouSerS - The open-source TCG
Software Stack - FAQ. Online im Internet:
http://trousers.sourceforge.net/faq.html (Zugriff am: 14.04.2014).
Abkürzungsverzeichnis
AIK
Attestation Identity Key
API
Application Programming Interface
ASCII
American Standard Code for
Information Interchange
CRTM
Core Root of Trust for Measurement
DAC
Discretionary Access Control
DRTM
Dynamic Root of Trust for
Measurement
EK
Endorsement Key
GRUB
Grand Unified Bootloader
IMA
Integrity Measurement Architecture
LCP
Lauch Control Policy
LSM
Linux Security Modules
MAC
Mandatory Access Control
MBR
Master Boot Record
MCS
Multi Category Security
MLE
Measured Launch Environment
MLS
Multi Level Security
NSA
National Security Agency
PCR
Platform Configuration Register
PTS
Platform Trust Services
QEMU
Quick-Emulator
RBAC
Role Based Access Control
RHEL
RedHat Enterprise Linux
SDK
Software Development Kit
SELinux
Security Enhanced Linux
SRK
Storage Root Key
SRTM
Static Root of Trust for Measurement
TBOOT
Trusted Boot
TC
Trusted Computing
TCG
Trusted Computing Group
TCP
Trusted Computing Platform
TCS
Trusted Computing System
TCSD
Trusted Computing Services Dämon
TOS
Trusted Operating System
TPM
Trusted Platform Module
TPC
Trusted Platform Computing
TSS
Trusted Software Stack
TXT
Trusted Execution Technology
UEFI
Unified Extensible Firmware Interface
VMM
Virtual Machine Manager
Darstellungsverzeichnis
Abbildung 1: Superuser-Zugriff auf die Gast-Systeme einschränken............. 8
Abbildung 2: Überblick der LSM Integration in den Linux Kernel (vgl. Sven
Vermeulen 2013, S. 10) ............................................................................... 14
Abbildung 3: Aufbau des SELinux Security-Contexts (vgl. Sven
Vermeulen 2013, S. 14) ............................................................................... 15
Abbildung 4: Aufbau des Trusted Computing Systems (Thomas
Müller 2008, S. 20)................................... Fehler! Textmarke nicht definiert.
Abbildung 5:Aufbau der Vertrauenskette (vgl. ebd. 2008, S. 53) ................ 24
Abbildung 6: Aufbau einer Trusted Computing Platform und deren
Komponenten............................................................................................... 35
Abbildung 7: Ablauf des Trusted Boot Vorgangs (vgl. Marcel
Selhorst; Christian Stüble; Felix Teerkorn o. J., S. 10) ................................ 39
Abbildung 8: Ablauf der Remote Attestation (Vgl. ebd. 2008, S. 56)............ 48
Abbildung 9: Abschottung eines virtuellen Servers mit Intels TXT (Vgl. ebd.
2012, S. 4) ................................................................................................... 63
Abbildung 10: Architektur von OpenAttestation (vgl. Gang Wei 2012a, S. 3)66
Abbildung 11: Komponenten von OpenAttestation (Vgl. ebd. 2012a, S. 6).. 67
Abbildung 12: Andwendungsfall für OpenAttestation (Vgl. ebd. 2012a, S. 5)
..................................................................................................................... 68
Listingsverzeichnis
Listing 1: Die Datei /etc/shadow mit ihren DAC Zugriffsrechten ................... 12
Listing 2: Security-Context für die /etc/shadow-Datei (vgl. ebd. 2008, S. 147)
..................................................................................................................... 18
Listing 3: Definition einer Domänentransition (vgl. ebd. 2008, S. 148)......... 18
Listing 4: Deaktivieren der Wechselmöglichkeit zwischen permissive und
enforced.................................................................................................... 30
Listing 5: Installation der mls-Richtlinie ....................................................... 30
Listing 6: Sicherheitslevel in der setrans.conf ........................................ 31
Listing 7: Datei mit einer neuen Sicherheitsstufe versehen ......................... 31
Listing 8: Installation der mls-Richtline ........................................................ 32
Listing 9: Kompilierung des SELinux-Moduls (vgl. o A 2013)....................... 32
Listing 10: Laden des neuen Moduls ........................................................... 32
Listing 11: System-Benutzer für die Administration anlegen ........................ 33
Listing 12: SELinux-Benutzer anlegen ......................................................... 33
Listing 13: Login-Zuordnung für SELinux erstellen ...................................... 33
Listing 14: Management-Zugriff für den iappl-Benutzer in libvirt anlegen
(vgl. Libvirt o. J.)........................................................................................... 34
Listing 15: Deaktivierung des sysadm_secadm-Moduls ............................. 34
Listing 16: Überprüfung der TPM Unterstützung im Kernel (vgl. Dejan
Lukan 2012) ................................................................................................. 36
Listing 17: Installation der TPM Software-Pakete ........................................ 37
Listing 18: Laden der Treiber für das TPM ................................................... 37
Listing 19: Aktivieren und Starten des TCSD ............................................... 37
Listing 20: Ausgabe der TPM Version.......................................................... 37
Listing 21: Fehlermeldung beim Zurücksetzen des TPM ............................. 38
Listing 22: Inbesitznahme des TPM Moduls (vgl. Dejan Lukan 2012).......... 38
Listing 23: Freigeben und Aktivierung des TPM (vgl. Dejan Lukan 2012).... 38
Listing 24: Abfrage des Endorsement Keys ................................................. 39
Listing 25: Von Trusted Grub benötigte Pakete nachinstallieren ................. 40
Listing 26: Kompilierung vonr TrustedGrub .................................................. 40
Listing 27: Korrekturen für neueste Automake und Autoconf Versionen ...... 41
Listing 28: Ergänzen des Automake Aufrufs für fehlende Testtreiber .......... 41
Listing 29: Abschließende Installation von TrustedGrub .............................. 42
Listing 30: Installation von Grub im Dateisystem ......................................... 42
Listing 31: Grub Beispielkonfiguration mit der Partition sda2 ....................... 43
Listing 32: Grub Menüeintrag für Fedora 20 ................................................ 43
Listing 33: Checkfile Syntax mit Beispiel ...................................................... 44
Listing 34: IMA Parameter für die Kernel Konfigurationsdatei ...................... 46
Listing 35: Installation des kernel-modules-extra Pakets .................... 46
Listing 36: Ausgabe des IMA Betriebssystem-Messprotokolls mit BeispielMesswerten.................................................................................................. 46
Listing 37: Installation des Platform-Trust-Services ..................................... 48
Listing 38: Einträge in der tcsd-Konfigurationsdatei für die IMA Verwendung
..................................................................................................................... 49
Listing 39: Konfiguration der ptsc.conf-Datei für die IMA Verwendung ... 50
Listing 40: PCR Konfiguration in der ptsc.conf-Datei (vgl. Seiji
Munetoh 2011b, S. 7) .................................................................................. 50
Listing 41: Initialisieren des Platform-Trust-Services (vgl. Seiji
Munetoh 2011b, S. 8) .................................................................................. 51
Listing 42: Selbsttest des Platform-Trust-Services durchführen (vgl. Seiji
Munetoh 2011b, S. 8) .................................................................................. 51
Listing 43: Erzeugung eines RSA-Schlüssels und Hinterlegung auf dem
System (vgl. Seiji Munetoh 2011b, S. 8) ...................................................... 51
Listing 44: Starten des ptsc-Services ........................................................... 51
Listing 45: Initialisierung des Sammlers (vgl. Seiji Munetoh 2011b, S. 8) .... 52
Listing 46: Remote-Attestierung durchführen und deren Ergebnis (vgl. Seiji
Munetoh 2011b, S. 9) .................................................................................. 52
Listing 47: Inhalt des Richtlinien-Moduls um Dateiklassen zu setzen .......... 55
Listing 48: SELinux-Typ für den iappl-Benutzer festlegen ........................... 55
Listing 49: Eintrag für einen Rollenwechsel in der sudo-Konfigurationsdatei
..................................................................................................................... 57
Listing 50: Datei, welche den IMA PCR-Wert beeinflusst ............................ 59
Bestätigung der Betreuer
Unterschrift des Betreuers bei der inet-logistics GmbH
Wolfurt, ……………………
………………………………………………….
Dipl.-Ing. Klaus Battlogg
Unterschrift des Betreuers an der Fachhochschule Vorarlberg
Dornbirn, ……………………
………………………………………………….
Dipl.-Ing. Armin Simma
Eidesstattliche Erklärung
Ich erkläre hiermit ehrenwörtlich, dass ich die vorliegende Arbeit
selbstständig angefertigt habe. Die aus fremden Quellen direkt oder indirekt
übernommenen Gedanken sind als solche kenntlich gemacht. Die Arbeit
wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch noch nicht
veröffentlicht.
Dornbirn, Juli 2014
……………………………..
Philipp Rusch

Trusted Boot und Mandatory Access Control: Vertrauenswürdige Ver

Transcription

Similar documents

IT-Sicherheit

Ausgewählte Themen der IT-Sicherheit

Materialsammlung — Grundlagen der Rechnerarchitektur

Wie lehrt man IT-Sicherheit am besten? ¨Uberblick, Klassifikation

Nr.15 - FRANKI Grundbau

TLS und SMTP - Strotmann.de

fotografie - mitp